<div dir="ltr"><div>Ed,</div><div><br></div><div>Thank you for the update! That is very informative, and it's very existing to hear that LLD can now build a runnable FreeBSD system. It's a great milestone. I personally want to build the entire FreeBSD system including the kernel within six months or at least in this year, and I believe it is a reasonable target based on the progress we've made so far in the last six months to the ELF linker.</div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 7, 2016 at 2:24 PM, Ed Maste via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@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">As I've mentioned before[1] I've been regularly attempting to build<br>
the FreeBSD/amd64 base system with lld, in order to keep track of<br>
progress and identify issues on an ongoing basis. As of last November<br>
a 'buildword' (i.e., userland build) ran to completion, with several<br>
workarounds applied to the FreeBSD base system. However, the result<br>
did not actually work.<br>
<br>
I'm pleased to report that I can now build a runnable FreeBSD system<br>
using lld as the linker (for buildworld), with a few workarounds and<br>
work-in-progress patches. I have not yet extensively tested the result<br>
but it is possible to login to the resulting system, and basic sanity<br>
tests I've tried are successful. Note that the kernel is still linked<br>
with ld.bfd.<br>
<br>
I have tracking PR[2] 23214 open for lld issues affecting the FreeBSD<br>
base system use case, and I'll briefly summarize the outstanding<br>
issues. Unless otherwise specified my workaround is to use ld.bfd to<br>
link the affected program.<br>
<br>
1. Symbol version support (PR 23231)<br>
<br>
FreeBSD relies on symbol version support in libc, libthr, and rtld for<br>
backwards compatibility and symbol visibility control.<br>
<br>
For testing I'm willing to build a system without symbol versioning.<br>
FreeBSD has a WITHOUT_SYMVER knob intended to enable this. It is<br>
currently broken, and I have patches[3][4] in review to fix it.<br>
<br>
I also added a "--hide-symbol" command to elfcopy, ELF Tool Chain's<br>
objcopy-equivalent. I use this to change the visibility of all symbols<br>
in libc_pic.a to hidden so that they do not end up incorrectly<br>
exported by ld-elf.so.1.<br>
<br>
2. Linker script expression support (PR 26731)<br>
<br>
The FreeBSD kernel linker scripts contain expressions not supported by<br>
lld - for example, ". = ALIGN(. != 0 ? 64 / 8 : 1);". I'm using ld.bfd<br>
to link the kernel for now.<br></blockquote><div><br></div><div>Comprehensive linker script support is the last major missing piece. It is not technically very difficult to do, but if you aim a high performance implementation (we do), it is a lot of stuff to consider, so we need a good design before start implementing. I have a few ideas to prototype, but that may take some time.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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></blockquote><div><br></div><div>"/lib" and other system-default directories are added to the search path by the default linker script in GNU ld.</div><div><br></div><div>I don't know how gold works. Does gold have the same issue as LLD?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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></blockquote><div><br></div><div>It is probably better to update FreeBSD boot loader rather than adding this option (which is probably for '80s Unix compatibles).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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></blockquote><div><br></div><div>Why does it need -dc option?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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></blockquote><div><br></div><div>This option seems like an alias to -L. Why are they still using -Y?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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></blockquote><div><br></div><div>After George's commit to support -r, does it work now?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The first two issues above are significant; the others can be<br>
addressed relatively easily but have simple workarounds and aren't<br>
holding up further progress.<br>
<br>
Thanks to all who have contributed to LLD's impressive progress over<br>
the last three months or so!<br>
<br>
[1] <a href="http://lists.llvm.org/pipermail/llvm-dev/2015-November/092572.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2015-November/092572.html</a><br>
[2] <a href="http://llvm.org/pr23214" rel="noreferrer" target="_blank">http://llvm.org/pr23214</a><br>
[3] <a href="https://reviews.freebsd.org/D5571" rel="noreferrer" target="_blank">https://reviews.freebsd.org/D5571</a><br>
[4] <a href="https://reviews.freebsd.org/D5572" rel="noreferrer" target="_blank">https://reviews.freebsd.org/D5572</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br></div></div>