LoongArch libunwind support

[kasperk81]

Given the nongnu libunwind port on loongarch is completed: libunwind/libunwind@c5f1d12, it should be relatively simpler to port the llvm libunwind (https://github.com/llvm/llvm-project/tree/main/libunwind).

@tangyouling, @SixWeining

[SixWeining]

Thanks. We are working on implementing the basic part of the backend. I think it would be better to wait this finish before supporting other sub-projects including clang, lld, compiler-rt, libunwind...

[MaskRay]

llvm-project libunwind can be used by libc++/libc++abi, but libc++/libc++abi can use libgcc_s.so.1 as well. If a program does not use C++ exceptions, libunwind is not a critical piece, so I see no reason blocking development of other components on libunwind.

I think it would be better to wait this finish before supporting other sub-projects including clang, lld, compiler-rt, libunwind...

Speaking of lld, clang driver, builtins part of compiler-rt, etc, I am more curious whether a new port does strange things.

[SixWeining]

Speaking of lld, clang driver, builtins part of compiler-rt, etc, I am more curious whether a new port does strange things.

What does "strange things" mean? Like adding a particular option to clang driver or lld?

[MaskRay]

Speaking of lld, clang driver, builtins part of compiler-rt, etc, I am more curious whether a new port does strange things.

What does "strange things" mean? Like adding a particular option to clang driver or lld?

Yes. An example is loongson/LoongArch-Documentation#9 such a relocation resolving design may add significant burden to the linker architecture.

[kasperk81]

@SixWeining, thanks for all the work. If some of these components can be worked on in parallel (as @MaskRay has pointed out) that would expedite the overall progress and win for everyone. Case in point, debugger (lldb) support on RISC-V which seems to be stuck: #55383, I hope LoongArch (or any new architecutre for that matter) won't get blocked like that. At the same time i can see how lack of ability to test on bare-metal can be a showstopper for someone porting an important toolchain component such as the debugger, which appears to be the case of RISC-V lldb story.

[SixWeining]

Yes. An example is loongson/LoongArch-Documentation#9 such a relocation resolving design may add significant burden to the linker architecture.

FYI. When adding new relocation type support was done, we would use the new relocation types but not the old ones (stack-based types).

And I agree with you, a new port should not add significant burden to the architecture(not only the linker).

[SixWeining]

@SixWeining, thanks for all the work. If some of these components can be worked on in parallel (as @MaskRay has pointed out) that would expedite the overall progress and win for everyone. Case in point, debugger (lldb) support on RISC-V which seems to be stuck: #55383, I hope LoongArch (or any new architecutre for that matter) won't get blocked like that. At the same time i can see how lack of ability to test on bare-metal can be a showstopper for someone porting an important toolchain component such as the debugger, which appears to be the case of RISC-V lldb story.

Thanks for your suggestion. But currently we don't have enough people to work on different components in parallel. It would be appreciated if someone in the community could help.

BTW, may I know where do you want to use the llvm libunwind? Does it block your work?