[libcxx-commits] [PATCH] D106703: [libunwind] adds a way to synthesise libgcc

[Fangrui Song via Phabricator via libcxx-commits]

MaskRay added a comment.

(I have implemented some missing parts of ld.lld symbol versioning recently: D107235 <https://reviews.llvm.org/D107235> D107234 <https://reviews.llvm.org/D107234> D107535 <https://reviews.llvm.org/D107535>. This ensures if we ever have a non-default version symbol, the version script should be good.)

My understanding of this patch:
Synthesize a symbol versioned libgcc_s.so.1 from libclang_rt.builtins-*.a and libunwind.a.

Many applications built with GCC libgcc_s.so.1 can run with their libgcc_s.so.1 runtime replaced with the synthesized one.

I may conjecture people's concern with the patch:

- maintenance burden. This is a new build way most users don't exercise (for now). Is unintentionally breaking ChromeOS builds ground for reverting their patches, assuming their patches are otherwise good.
- does this script fit in libunwind/ or should it sit somewhere else?

I am chatting with a few others on thoughts:)

---

Having a version script for every architecture is difficult to maintain.
For a new symbol, a contributor needs to figure out every version map.

I think a better approach is to use C preprocessed version script file with conditional macros like `#ifdef __x86_64__`.
Most symbols are shared anyway.



================
Comment at: libunwind/gcc_s-aarch64.ver:147
+
+Unversioned {
+  __extendhftf2;
----------------
This just makes the symbol `emutls_init@@Unversioned`. It doesn't mean unversioned.

You can just omit the symbols.

`local: *;` will localize these unversioned symbols, so `local: *;` cannot be used.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D106703/new/

https://reviews.llvm.org/D106703