<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 21, 2017 at 10:56 AM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I just skimmed through a few files. What I noticed first is that the code is pretty well-commented. I appreciate whoever wrote this.</div></blockquote><div><br></div><div>Looking at the history, I believe the people that wrote it are Rod Evans (rie; Rod.Evans@Sun.COM) and Ali Bahrami (ab196087; Ali.Bahrami@Sun.COM), though those emails are likely defunct now.</div><div><br></div><div><a href="http://src.illumos.org/source/history/illumos-gate/usr/src/cmd/sgs/libld/common/">http://src.illumos.org/source/history/illumos-gate/usr/src/cmd/sgs/libld/common/</a></div><div><br></div><div><br></div><div>Rod seems to have had a "Surfing With a Linker Alien" blog series: <a href="https://blogs.oracle.com/rie/">https://blogs.oracle.com/rie/</a></div><div><br></div><div>This one contains a good overview of the solaris SGS (software generation subsystem; i.e. linkers, loaders, etc.): <a href="https://blogs.oracle.com/rie/entry/the_link_editors_a_source">https://blogs.oracle.com/rie/entry/the_link_editors_a_source</a></div><div><br></div><div>Another good solaris resource on linkers that I had forgotten about is "Solaris Linker and Libraries Guide": <a href="http://docs.oracle.com/cd/E19253-01/817-1984/">http://docs.oracle.com/cd/E19253-01/817-1984/</a></div><div><br></div><div><div>-- Sean Silva</div></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"> A few random facts I found from the source code:<div><br></div><div> - it uses AVL tree for the symbol table</div><div> - --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</div><div> - it exits at end of main without freeing up the memory for performance reasons</div><div> - the default entry points are _start *and* main. (In LLD _start is the only default entry point name.)</div></div><div class="gmail-HOEnZb"><div class="gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 18, 2017 at 3:34 AM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Recently LLD made it to the front page of HN (yay!): <a href="https://news.ycombinator.com/item?id=13670458" target="_blank">https://news.ycombinator.com/i<wbr>tem?id=13670458</a><br></div><div>This comment about the Solaris linker surprised me: <a href="https://news.ycombinator.com/item?id=13672364" target="_blank">https://news.ycombinator.c<wbr>om/item?id=13672364</a></div><div><br></div><div>"""</div><div>> To me, the biggest advantage is cross compiling</div><div><br></div><div>Not all system linkers have this problem. For example, Solaris ld(1) is perfectly capable of cross-linking any valid ELF file.</div><div>"""</div><div><br></div><div>This got me interested in looking at what the solaris linker was like.</div><div>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).</div><div><br></div><div><br></div><div><br></div><div>The basic layout seems to be:</div><div><a href="http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/sgs/ld/common/ld.c" target="_blank">http://src.illumos.org/source/<wbr>xref/illumos-gate/usr/src/cmd/<wbr>sgs/ld/common/ld.c</a><br></div><div>This is where `main` is.</div><div><br></div><div>The actual linker has a "main in a library" type interface that is called into from main() by:</div><div><br></div><div><div>718<span class="gmail-m_-904853532799671237m_8645351401842037046m_820910608402612148gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>/* Call the libld entry point for the specified ELFCLASS */</div><div>719<span class="gmail-m_-904853532799671237m_8645351401842037046m_820910608402612148gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>if (class == ELFCLASS64)</div><div>720<span class="gmail-m_-904853532799671237m_8645351401842037046m_820910608402612148gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>return (ld64_main(argc, argv, mach));</div><div>721<span class="gmail-m_-904853532799671237m_8645351401842037046m_820910608402612148gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>else</div><div>722<span class="gmail-m_-904853532799671237m_8645351401842037046m_820910608402612148gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>return (ld32_main(argc, argv, mach));</div></div><div><br></div><div><br></div><div>The rest of the code is in "libld". The header is here:</div><div><a href="http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/sgs/include/libld.h" target="_blank">http://src.illumos.org/source/<wbr>xref/illumos-gate/usr/src/cmd/<wbr>sgs/include/libld.h</a><br></div><div><br></div><div>There seems to be a huge "context" struct `struct ofl_desc`: <a href="http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/sgs/include/libld.h#241" target="_blank">http://src.illumos.<wbr>org/source/xref/illumos-gate/u<wbr>sr/src/cmd/sgs/include/libld.h<wbr>#241</a></div><div>(it does have a couple globals in <a href="http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/sgs/libld/common/globals.c" target="_blank">http://src.illumos.org/sour<wbr>ce/xref/illumos-gate/usr/src/c<wbr>md/sgs/libld/common/globals.c</a></div><div>And also the "Target" struct is a global apparently: <a href="http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/sgs/libld/common/_libld.h#47" target="_blank">http://src.illumos.org/source/<wbr>xref/illumos-gate/usr/src/cmd/<wbr>sgs/libld/common/_libld.h#47</a></div><div>)</div><div><br></div><div>The code itself is mostly here:</div><div><a href="http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/sgs/libld/common/" target="_blank">http://src.illumos.org/source/<wbr>xref/illumos-gate/usr/src/cmd/<wbr>sgs/libld/common/</a><br></div><div><br></div><div>The libld "main" function seems to be in:</div><div><a href="http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/sgs/libld/common/ldmain.c#144" target="_blank">http://src.illumos.org/source/<wbr>xref/illumos-gate/usr/src/cmd/<wbr>sgs/libld/common/ldmain.c#144</a><br></div><div><br></div><div>The function that handles individual sections in object files is `process_elf` in:</div><div><a href="http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/sgs/libld/common/files.c#2525" target="_blank">http://src.illumos.org/source/<wbr>xref/illumos-gate/usr/src/cmd/<wbr>sgs/libld/common/files.c#2525</a><br></div><div><br></div><div><div><a href="http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/sgs/libld/common/README.XLINK" target="_blank">http://src.illumos.org/source/<wbr>xref/illumos-gate/usr/src/cmd/<wbr>sgs/libld/common/README.XLINK</a></div></div><div><br></div><div>(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))</div><div><br></div><div><br></div><div><br></div><div>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.</div><div><br></div><div>(for the record, `illumos-gate/usr/src/cmd/sgs/<wbr>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)</div><div><br></div><div><br></div><div><br></div><div><br></div><div>There even seems to be a simple "libelf": <a href="http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/sgs/libelf/common/" target="_blank">http://src.illumos.o<wbr>rg/source/xref/illumos-gate/us<wbr>r/src/cmd/sgs/libelf/common/</a></div><div>Main interface is the "struct Elf": <a href="http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/sgs/libelf/common/decl.h#270" target="_blank">http://src.illumos.org/source/<wbr>xref/illumos-gate/usr/src/cmd/<wbr>sgs/libelf/common/decl.h#270</a></div><div>`struct Elf` also handles archives.</div><div><br></div><div>It seems to be roughly libobject-like, though it seems to support writing.</div><div>There are some "demos" here: <a href="http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/sgs/libelf/demo/" target="_blank">http://src.illumos.org/s<wbr>ource/xref/illumos-gate/usr/sr<wbr>c/cmd/sgs/libelf/demo/</a> (note the README)</div><div><br></div><div>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.</div><span class="gmail-m_-904853532799671237HOEnZb"><font color="#888888"><div><br></div><div><br></div><div>-- Sean Silva</div><div><br></div><div><br></div><div><br></div></font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>