[llvm-dev] [lld] Has anybody ever run into the Solaris linker before?
Rui Ueyama via llvm-dev
llvm-dev at lists.llvm.org
Tue Feb 21 10:56:58 PST 2017
I just skimmed through a few files. What I noticed first is that the code
is pretty well-commented. I appreciate whoever wrote this. A few random
facts I found from the source code:
- it uses AVL tree for the symbol table
- --wrap is implemented using an additional AVL tree. So if --wrap is in
use, a symbol name is translated by the additional AVL tree before looking
up the main symbol table
- it exits at end of main without freeing up the memory for performance
- the default entry points are _start *and* main. (In LLD _start is the
only default entry point name.)
On Sat, Feb 18, 2017 at 3:34 AM, Sean Silva <chisophugis at gmail.com> wrote:
> Recently LLD made it to the front page of HN (yay!):
> This comment about the Solaris linker surprised me:
> > To me, the biggest advantage is cross compiling
> Not all system linkers have this problem. For example, Solaris ld(1) is
> perfectly capable of cross-linking any valid ELF file.
> This got me interested in looking at what the solaris linker was like.
> I had known that Solaris had done quite a few innovations in the linker
> space, but I had never actually looked at their iinker (the time I spent
> interacting with Solaris/illumos was related to DTrace stuff and happened
> before I started working on linkers).
> The basic layout seems to be:
> This is where `main` is.
> The actual linker has a "main in a library" type interface that is called
> into from main() by:
> 718 /* Call the libld entry point for the specified ELFCLASS */
> 719 if (class == ELFCLASS64)
> 720 return (ld64_main(argc, argv, mach));
> 721 else
> 722 return (ld32_main(argc, argv, mach));
> The rest of the code is in "libld". The header is here:
> There seems to be a huge "context" struct `struct ofl_desc`:
> (it does have a couple globals in http://src.illumos.org/sour
> And also the "Target" struct is a global apparently:
> The code itself is mostly here:
> The libld "main" function seems to be in:
> The function that handles individual sections in object files is
> `process_elf` in:
> (one interesting thing is that besides being used for the regular `ld`
> command line program, libld.so is also used implicitly if you try to dlopen
> a relocatable object (which is a bit weird))
> I haven't traced through all of it yet. Has anybody stared at this code?
> How does it compare architecturally with LLD? If you're looking through for
> the first time, please post any findings/insights in this thread so others
> can follow along.
> (for the record, `illumos-gate/usr/src/cmd/sgs/libld/common % wc -l *.c`
> gives about 45k lines of code, so LLD/ELF is still quite a bit slimmer,
> though giving solaris libld a factor of 2 handicap due to using C vs C++
> brings them basically to parity)
> There even seems to be a simple "libelf": http://src.illumos.o
> Main interface is the "struct Elf": http://src.illumos.org/source/
> `struct Elf` also handles archives.
> It seems to be roughly libobject-like, though it seems to support writing.
> There are some "demos" here: http://src.illumos.org/s
> ource/xref/illumos-gate/usr/src/cmd/sgs/libelf/demo/ (note the README)
> It seems like it tries to paper over the fact that writing can cause it to
> have to do O(the entire file) work if it needs to slide sections around /
> fixup offsets (haven't looked super closely though). E.g. it seems to try
> to transparently handle the case where you append extra data to a section.
> It doesn't seem to handle "symbols" explicitly (just exposes the raw
> section data), so it doesn't need to worry about operations like "convert a
> local symbol to weak" which requires rewriting all sorts of stuff.
> -- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev