[llvm-dev] Linking the FreeBSD base system with lld -- status update

[Ed Maste via llvm-dev]

On 7 March 2016 at 23:16, Rui Ueyama <ruiu at google.com> wrote:
>
>> 3. Library search paths
>>
>> In FreeBSD /usr/lib/libc.so is a linker script that contains "GROUP (
>> libc.so.7 libc_nonshared.a libssp_nonshared.a )". ld.bfd includes a
>> built-in /lib search path and finds /lib/libc.so.7 there. lld relies
>> only on the -L paths specified on the command line, and cannot locate
>> libc.so.7. As a workaround I've changed /usr/lib/libc.so to include
>> the full path.
>
> "/lib" and other system-default directories are added to the search path by
> the default linker script in GNU ld.
>
> I don't know how gold works. Does gold have the same issue as LLD?

I haven't tried a buildworld with gold, but a quick search suggests
gold does have /lib and /usr/lib paths baked-in. I linked a hello
world with gold, and it does not show the problem mentioned above.

>> 4. -N/--omagic option
>>
>> -N makes the text and data sections RW and does not page-align data.
>> It is used by boot loader components.
>
> It is probably better to update FreeBSD boot loader rather than adding this
> option (which is probably for '80s Unix compatibles).

Indeed. For those boot components that do need a single RW segment I
think it would be better accomplished with a linker script anyway.

>> 5. -dc option
>>
>> -dc assigns space to common symbols when producing relocatable output
>> (-r). It is used by the /rescue build, which is a single binary
>> assembled from a collection of individual tools (sh, ls, fsck, ...)
>
>
> Why does it need -dc option?

The "crunchide" tool used in building the rescue binary segfaults when
operating on an object with common symbols, and a comment in the
source claims:

This program relies on the use of the linker's -dc flag to actually
put global bss data into the file's bss segment (rather than leaving
it as undefined "common" data).

but that still does not explain why it's necessary. I believe it could
be modified to avoid the requirement for now.

However, there is a todo item in the source: arrange that all the BSS
segments start at the same address, so that the final crunched binary
BSS size is the max of all the component programs' BSS sizes, rather
than their sum. It seems this would require -dc along with some linker
script magic.

>> 6. -Y option
>>
>> -Y adds a path to the default library search path. It is used by the
>> lib32 build, which provides i386 builds of the system libraries for
>> compatibility with i386 applications.
>
> This option seems like an alias to -L. Why are they still using -Y?

It's not exactly an alias: -Y adds the path to the list of default
search paths, which are searched after any -L paths. I suspect it's
done this way to simplify setting up the correct path ordering despite
building up the compiler invocation through several levels of make
variables. Anyway, I believe we can address the requirement using only
-L, and this one is a low priority.

>> 7. Use of -r to convert a binary file into an ELF object
>>
>> A tool for loading firmware into a wireless USB device includes a
>> built-in copy of the firmware image, and the image is converted to an
>> ELF file using ld -r.
>
> After George's commit to support -r, does it work now?

George's work addressed the other uses of -r in the FreeBSD tree, but
not this one.

The invocation here is:
ld -b binary -d -warn-common -r -d -o ar5523.o ar5523.bin
the resulting ar5523.o is then linked into the executable, and
accessed using the _binary_ar5523_bin_start and _binary_ar5523_bin_end
symbols created by the linker.

I don't think this is a reasonable case to support in lld. In FreeBSD
we can achieve the same result with something like:
objcopy -I binary -O elf64-x86-64 ar5523.bin ${.TARGET}
or just create a .c source file with the firmware contents as an array.