<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 7, 2016 at 6:47 PM, Ed Maste <span dir="ltr"><<a href="mailto:emaste@freebsd.org" target="_blank">emaste@freebsd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 7 March 2016 at 23:16, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
><br>
>> 3. Library search paths<br>
>><br>
>> In FreeBSD /usr/lib/libc.so is a linker script that contains "GROUP (<br>
>> libc.so.7 libc_nonshared.a libssp_nonshared.a )". ld.bfd includes a<br>
>> built-in /lib search path and finds /lib/libc.so.7 there. lld relies<br>
>> only on the -L paths specified on the command line, and cannot locate<br>
>> libc.so.7. As a workaround I've changed /usr/lib/libc.so to include<br>
>> the full path.<br>
><br>
> "/lib" and other system-default directories are added to the search path by<br>
> the default linker script in GNU ld.<br>
><br>
> I don't know how gold works. Does gold have the same issue as LLD?<br>
<br>
</span>I haven't tried a buildworld with gold, but a quick search suggests<br>
gold does have /lib and /usr/lib paths baked-in. I linked a hello<br>
world with gold, and it does not show the problem mentioned above.</blockquote><div><br></div><div>This should be addressed in r262910 that I've just submitted.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
>> 4. -N/--omagic option<br>
>><br>
>> -N makes the text and data sections RW and does not page-align data.<br>
>> It is used by boot loader components.<br>
><br>
> It is probably better to update FreeBSD boot loader rather than adding this<br>
> option (which is probably for '80s Unix compatibles).<br>
<br>
</span>Indeed. For those boot components that do need a single RW segment I<br>
think it would be better accomplished with a linker script anyway.<br>
<span class=""><br>
>> 5. -dc option<br>
>><br>
>> -dc assigns space to common symbols when producing relocatable output<br>
>> (-r). It is used by the /rescue build, which is a single binary<br>
>> assembled from a collection of individual tools (sh, ls, fsck, ...)<br>
><br>
><br>
> Why does it need -dc option?<br>
<br>
</span>The "crunchide" tool used in building the rescue binary segfaults when<br>
operating on an object with common symbols, and a comment in the<br>
source claims:<br>
<br>
This program relies on the use of the linker's -dc flag to actually<br>
put global bss data into the file's bss segment (rather than leaving<br>
it as undefined "common" data).<br>
<br>
but that still does not explain why it's necessary. I believe it could<br>
be modified to avoid the requirement for now.<br>
<br>
However, there is a todo item in the source: arrange that all the BSS<br>
segments start at the same address, so that the final crunched binary<br>
BSS size is the max of all the component programs' BSS sizes, rather<br>
than their sum. It seems this would require -dc along with some linker<br>
script magic.<br>
<span class=""><br>
>> 6. -Y option<br>
>><br>
>> -Y adds a path to the default library search path. It is used by the<br>
>> lib32 build, which provides i386 builds of the system libraries for<br>
>> compatibility with i386 applications.<br>
><br>
> This option seems like an alias to -L. Why are they still using -Y?<br>
<br>
</span>It's not exactly an alias: -Y adds the path to the list of default<br>
search paths, which are searched after any -L paths. I suspect it's<br>
done this way to simplify setting up the correct path ordering despite<br>
building up the compiler invocation through several levels of make<br>
variables. Anyway, I believe we can address the requirement using only<br>
-L, and this one is a low priority.</blockquote><div><br></div><div>Agreed. This should probably be addressed by updating the program that needs -Y. GNU ld's manual is terse about this option and says that this is for Solaris compatibility. It does make much less sense for us to add this option for Solaris-compatibility-through-a-GNU-tool.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
>> 7. Use of -r to convert a binary file into an ELF object<br>
>><br>
>> A tool for loading firmware into a wireless USB device includes a<br>
>> built-in copy of the firmware image, and the image is converted to an<br>
>> ELF file using ld -r.<br>
><br>
> After George's commit to support -r, does it work now?<br>
<br>
</span>George's work addressed the other uses of -r in the FreeBSD tree, but<br>
not this one.<br>
<br>
The invocation here is:<br>
ld -b binary -d -warn-common -r -d -o ar5523.o ar5523.bin<br>
the resulting ar5523.o is then linked into the executable, and<br>
accessed using the _binary_ar5523_bin_start and _binary_ar5523_bin_end<br>
symbols created by the linker.<br>
<br>
I don't think this is a reasonable case to support in lld. In FreeBSD<br>
we can achieve the same result with something like:<br>
objcopy -I binary -O elf64-x86-64 ar5523.bin ${.TARGET}<br>
or just create a .c source file with the firmware contents as an array.<br>
</blockquote></div><br></div></div>