[PATCH] D28791: [compiler-rt][crt] Simple crtbegin and crtend implementation

[Petr Hosek via Phabricator via llvm-commits]

phosek added a comment.

In https://reviews.llvm.org/D28791#663813, @joerg wrote:

> It is functional only if a number of number of run time choices are made in the right way. That's exactly the reason why I am against shipping those files in first place: if you pick the wrong, you get a nicely linking binary that is magically broken much much later.
>
> The choices available to the run time are:
>  (1) Should EH frame registration be attemped?
>  (2) Who is responsible for iterating .ctor/.dtor?
>  (3) Is __cxa_atexit supported by the platform?
>  (4) Are Java types supported?
>
> The current version is noticably wrong for (3) on most modern systems, glibc include. This would prevent global dtors and the like in shared libraries be skipped.
>  Getting (1) wrong can break reasonable caching in libunwind, so it is also quite important.
>  Getting (2) wrong won't matter on newer glibc distros, but there are still enough systems that don't use INIT_ARRAY/FINI_ARRAY on non-EABI-ARM.
>
> (4) is likely not relevant anymore.


I'd definitely like to address (1), (2) and (3) which are needed on Linux. Right now, this is really critical for Fuchsia where we cannot use libgcc.a because of license and we need at least a minimal crtbegin.o/crtend.o. The current implementation is sufficient for our use case. Would it be acceptable to you if I restrict the current implementation only to Fuchsia to unblock us, and then continue working on this to address (1), (2) and (3)?


Repository:
  rL LLVM

https://reviews.llvm.org/D28791