<div dir="ltr"><div>This is a followup to the discussion that started in D28791. To provide the context, we need a way to provide __dso_handle in Fuchsia. __dso_handle symbol is mandated by C++ ABI with a value which is an address in one of the object's segments, and as such this symbol has to be included statically and cannot be a part of a shared library. Different systems provide it differently:</div><div><br></div><div>1. On GNU/Linux systems, it's defined in crtbegin.o which is provided by libgcc.</div><div>3. On Android, it's defined in crtbegin.o provided by the Bionic C library.</div><div>3. FreeBSD/OpenBSD/NetBSD provide crtbegin.o as part of the system.</div><div>4. On macOS, __dso_handle is generated by the linker.</div><div><br></div><div>We don't think __dso_handle should be provided by the C library. The name __dso_handle is not part of the ABI contract with the C library, it's entirely a name chosen by the C++ ABI. Since C++ front-end defines the reference to __dso_handle, it should be the compiler that provides the definition of it somewhere. The reason GCC defines it in crtbegin.o is purely pragmatic; crtbegin.o is an object file that's already linked into every shared library and every executable, although there's no principled reason for __dso_handle to be defined there.</div><div><br></div><div>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.</div><div><br></div><div>There several options that we discussed for approaching this:</div><div><br></div><div>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.</div><div><br></div><div>3. Define __dso_handle as part of the Clang builtin library in compiler-rt. This is the solution we're currently using with a downstream patch (<a href="https://fuchsia.googlesource.com/third_party/compiler-rt/+/6c9f8c6ba77090158373490ac010437603c8ff50">https://fuchsia.googlesource.com/third_party/compiler-rt/+/6c9f8c6ba77090158373490ac010437603c8ff50</a>). It works because builtins are already built as a static library, but I'm not sure whether it's correct from the layering point of view.<br></div><div><br></div><div>3. A cleanest solution from the layering perspective would be add another archive library to libc++abi, e.g. libc++abi_nonshared.a, that will only contain the definition of __dso_handle. The ABI linker script that's generated by libc++ could then include this library into every link. This work even on systems that already provide __dso_handle. The only aspect that might be somewhat complicated is the case when the generation of the ABI linker script, e.g. when the ABI library is statically linked into libc++. In this case, the libc++abi_nonshared.a would either have to be linked manually or we would need to generate another linker script.</div><div><br></div><div>4. Finally, we could extend LLD to define the __dso_handle symbol, following the macOS model. This would be a fine solution for us since we already use LLD as our default linker, but it may not be as clean as other solutions (i.e. using built-in magic for things that can be done via general purpose facilities).</div><div><br></div><div>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.</div></div>