[llvm-dev] Providing __dso_handle in LLVM

Jonathan Roelofs via llvm-dev llvm-dev at lists.llvm.org
Mon Jun 5 07:25:58 PDT 2017

On 6/1/17 9:47 PM, Petr Hosek via llvm-dev wrote:
> From the layering point of view, __dso_handle really belongs in
> libc++abi. However, for implementation reasons it needs to be included
> statically into each final link (whether executable or shared library),
> even when libc++abi is built as a shared library.
> There several options that we discussed for approaching this:
> 1. Provide crtbegin.o/crtend.o implementation in compiler-rt. This is
> the approach I took in D28791. In Fuchsia, we don't need
> crtbegin.o/crtend.o at all, but having these may be useful elsewhere,
> like LLVM-based Linux distributions that won't ship libgcc and will need
> to provide their own crtbegin.o/crtend.o. However, this approach has
> been met with a lot of pushback, where the primary reason has been the
> fact that crtbegin.o/crtend.o contain a lot of legacy cruft that may be
> difficult to get right across all different systems.

I want this for baremetal too, and have had similar pushback when trying 
to implement it upstream.

Newlib doesn't provide its own crt{begin,end}.o, and instead it relies 
on the one from libgcc (which we can't assume will be there in a pure 
llvm installation). From that point of view, it has always made sense to 
me to have them as an optional part of compiler_rt.

> Do you have any opinion about these options? I'd like to come up with a
> generally acceptable solution and implementing it in upstream rather
> than maintaining downstream changes.



> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded / Siemens

More information about the llvm-dev mailing list