[llvm-dev] Orc JIT vs. devtoolset-6

[David Chisnall via llvm-dev]

On 28/08/2019 15:21, Geoff Levner via llvm-dev wrote:
> The libstdc++.so file that comes with devtoolset-6 is actually not a DSO 
> but a small text file containing this:
> 
>      /* GNU ld script
>         Use the shared library, but some functions are only in
>         the static library, so try that secondarily.  */
>      OUTPUT_FORMAT(elf64-x86-64)
>      INPUT ( /usr/lib64/libstdc++.so.6 -lstdc++_nonshared )
> 
> So the question, I think, is: what exactly does the GNU linker do with 
> this information, and is there a way to replicate its behavior in Orc JIT?

This is a fairly simple linker script that tells the linker to 
explicitly link /usr/lib64/libstdc++.so.6 and do the equivalent of 
adding -lstdc++_nonshared to the command line.  It sounds as if this is 
done to enable long-term ABI stability, so anything that is guaranteed 
to be safe over a long-term release cycle goes in 
/usr/lib64/libstdc++.so.6 and everything else goes in {some 
compiler-release specific path}/libstdc++_nonshared.a.

How to solve this depends a bit on whether you want to solve the general 
case of this or whether you want to special case libstdc++ on RedHat 
systems.  If it's the latter, then the simplest thing to do is link 
libstdc++_nonshared.a with the --whole-archive flag, to pull all of the 
symbols from the .a into the main binary.  This will let the JIT find 
them in the main binary and everything should just work.

If you want to solve the general case, then whatever you are using to 
load .so files needs to learn how to parse linker scripts.  There's 
logic in LLD for doing this, but I don't believe anyone has implemented 
it in ORC.  You'd then need to load all of the things that are 
referenced by the linker script.  You'd probably only need to handle a 
fairly small subset of the things in linker scripts, because anything 
beyond 'link these other objects' is unlikely to appear in a .so linker 
script.

David