TCWG-901 Investigate lld as a system linker - Installed lld as the system linker on my Chromebook and attempted to build and run things to see what breaks - Only one unknown concrete problem found so far, thunks to undefined symbols with PLT entries don't work. This seems to be common in python C extensions that are dlopened from python, and call back to the interpreter. -- I have a downstream fix (TCWG-919), with this fixed the test-suite can run with lld as the linker through the pip install (SQLAlchemy has C extensions). - As thought previously, clang is too big to link without thunks. - Attempted to make a simple add thunks to all branches to see if I could get clang to link. Sadly this won't work as lld only permits one thunk per symbol and this might be out of range of the caller as well. - Some thoughts and experiments on how much of llvm, compiler-rt, clang and libc++ can be linked with lld. I'm currently thinking of altering my lld driver to automatically switch to ld.bfd after a relocation out of range link error. I want to try and get a lld linked clang + compiler-rt +libc++ system running.

TCWG-683 lld support for branches to unresolved weak references - Now upstream

Also: - A lot of rebasing of downstream patches as some refactoring is going on to make lld more flexible. - Some inconclusive investigation into weak reference behaviour in GNU ld. The ARM and AArch64 ld.bfd linkers will put a dynamic relocation on a got slot generated by for an unresolved weak reference. The x86 linkers do not, they statically resolve the got slot to 0. - Some inconclusive investigations into trying to work out what packages to build to test lld. With the exception of very large programs ld seems to successfully complete the link for all programs. Whether it has done so correctly or not is another matter. -- Currently thinking about whether I can build a BSD make world on a raspberry pi.

Plans for next week: - Bring TCWG-901 to a close and work out what to work on next.