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

[Rui Ueyama via llvm-dev]

On Mon, Mar 7, 2016 at 6:47 PM, Ed Maste <emaste at freebsd.org> wrote:

> 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.


This should be addressed in r262910 that I've just submitted.


>
> >> 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.


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.

>> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160307/3fb56d5b/attachment.html>