<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 2, 2017 at 5:03 PM, Petr Hosek <span dir="ltr"><<a href="mailto:phosek@chromium.org" target="_blank">phosek@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div dir="ltr">On Fri, Jun 2, 2017 at 1:01 PM Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 1, 2017 at 8:47 PM, Petr Hosek via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank">https://fuchsia.googlesource.<wbr>com/third_party/compiler-rt/+/<wbr>6c9f8c6ba77090158373490ac01043<wbr>7603c8ff50</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></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Do you have any reason to believe that 4. will be that complicated? If it's just a matter of defining a symbol that needs to be guaranteed to be in the current dso, then the linker seems like the natural place to do it since the linker is the single point of truth for creating the DSO's in the first place. It seems like the other solutions have quite a bit of unnecessary complexity due to not being implemented in a "single point of truth". The hacky nature of the crt*.o hacks (which are basically piggybacking on the assumption that those are linked into every DSO) is made clear because Fuchsia differs in this regard, so it wasn't a true single point of truth.</div><div><br></div><div>Defining __dso_handle when using fuchsia emulation should only be a couple lines of code in LLD, right?</div></div></div></div></blockquote><div><br></div></span><div>It's actually pretty straightforward to do this in LLD, see <a href="https://reviews.llvm.org/D33856" target="_blank">https://reviews.llvm.org/<wbr>D33856</a>. </div></div></div>
</blockquote></div><br></div><div class="gmail_extra">Since this is literally one line of code and seems to solve the problem in full generality, it seems like the best approach. As long as this doesn't break/affect other platforms, I don't see any reason not to use this approach.</div><div class="gmail_extra"><br></div><div class="gmail_extra">-- Sean Silva</div></div>