<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 16, 2016 at 9:05 AM, Rafael Espíndola via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@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">On 16 November 2016 at 11:57, Ed Maste via llvm-commits<br>
<span class=""><<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
> I'm now looking in more detail at the final two issues preventing us<br>
> from fully using lld for building FreeBSD userland and kernel. The<br>
> issues have been discussed in sub-threads in the past, but as we're<br>
> very close to building FreeBSD with lld "out of the box" I'm focusing<br>
> on final resolutions for them. I need to either have lld gain the last<br>
> pieces of missing functionality, or commit to a permanent change in<br>
> FreeBSD.<br>
<br>
</span>Thanks!<br>
<span class=""><br>
>  * crunchide.c - tiptoes through a symbol table, hiding all defined<br>
>  *      global symbols.  Allows the user to supply a "keep list" of symbols<br>
>  *      that are not to be hidden.  This program relies on the use of the<br>
>  *      linker's -dc flag to actually put global bss data into the file's<br>
>  *      bss segment (rather than leaving it as undefined "common" data).<br>
>  *<br>
>  *      The point of all this is to allow multiple programs to be linked<br>
>  *      together without getting multiple-defined errors.<br>
>  *<br>
>  *      For example, consider a program "foo.c".  It can be linked with a<br>
>  *      small stub routine, called "foostub.c", eg:<br>
>  *          int foo_main(int argc, char **argv){ return main(argc, argv); }<br>
>  *      like so:<br>
>  *          cc -c foo.c foostub.c<br>
>  *          ld -dc -r foo.o foostub.o -o foo.combined.o<br>
>  *          crunchide -k _foo_main foo.combined.o<br>
>  *      at this point, foo.combined.o can be linked with another program<br>
>  *      and invoked with "foo_main(argc, argv)".  foo's main() and any<br>
>  *      other globals are hidden and will not conflict with other symbols.<br>
<br>
</span>And it doesn't know how to hide common symbols, so it depends on they<br>
being pre allocated to .bss.<br>
<span class=""><br>
> In order to make this work with lld I need to do one of three things:<br>
><br>
> 1) compile the object files with -fno-common<br>
> 2) give crunchide some simple linking ability, so that it can convert<br>
> common symbols into allocated .bss symbols<br>
> 3) add -dc support to lld<br>
><br>
> Rafael previously suggested #1. It's feasible, but makes the crunch<br>
> build system slightly less portable (in that it couldn't be used with<br>
> other software that relies on common symbol behaviour). It also<br>
> requires that we build a second set of objects for the rescue build,<br>
> if -fno-common isn't applied to the "normal" build of the tools.<br>
<br>
</span>So, right now if a foo.o is in both /bin/sh and the rescue system you<br>
only compile it once? I would assume that the one in the rescue system<br>
was a special minimal version. If the size is not an issue, why do you<br>
"concatenate" multiple program into one? Why not just have static<br>
versions of sh, ls, etc?<br>
<span class=""><br>
> Rafael/Rui, do you think it's reasonable to add -dc to lld?<br>
<br>
</span>Now that we use synthetic input sections it should not be too<br>
horrible. I would just like to understand what is the need a bit<br>
better.<br></blockquote><div><br></div><div>Yes, I guess that it shouldn't be hard to add this feature to LLD now, and I also guess that the change would be a local one (you wouldn't change many places in the linker.)</div></div></div></div>