On 2020-04-16, Kevin O'Connor wrote:
On Tue, Apr 14, 2020 at 12:07:54PM -0700, Fāng-ruì Sòng wrote:
On Mon, Apr 6, 2020 at 5:55 PM Fangrui Song maskray@google.com wrote:
This patch series make seabios linkable with lld.
[...]
Ping...
And https://mail.coreboot.org/hyperkitty/list/seabios@seabios.org/thread/CNOAJWO... "[PATCH v2] Use readelf -WSrs instead of objdump -thr so that llvm-readelf can be used as a replacement"
Thanks.
As I understand the status:
- patch 3 is not something I'm comfortable merging
You mean "Makefile: Change ET_EXEC to ET_REL so that lld can link bios.bin.elf"
Let me add more descriptions. I am a maintainer of lld ELF (I contributed most features and wrote most items of lld 9/10's release notes).
A linker accepts ET_REL as regular object files. The input sections are taken to make up output sections. The input symbols are taken to track dependencies and resolve relocations.
A linker accepts ET_DYN as shared objects. Input sections are ignored. Only symbols are used. Many sections are synthesized by a linker and do not make sense to be reused as input.
ET_EXEC, position dependent executables. The type is more similar to ET_DYN. Many synthesized sections (.hash .gnu.hash .plt .dynstr .dynsym) do not make sense to be reused as input. Sometimes there are needs to read its symbols so that another component can know which symbols should be exported. For this use case, --just-symbols is used.
seabios' use of ET_EXEC is very different. I have built thousands third-party pieces of software. seabios and (for a short period because I have fixed it) the Linux kernel are the only two cases an ET_EXEC input's sections are used. The symbol table appears to be ignored. This is really an unusual use case. Another lld maintainer and I think this is just a very error-prone case. I hence decide that this is not worth supporting. GNU ld accepts it, but note that GNU gold disallows it as well https://sourceware.org/git/?p=binutils-gdb.git;a=blob;hb=49d1d1f53df552f0592...
Since seabios just uses ET_EXEC as something similar to an ET_REL. Binary patching the file seems the most portable approach. (This Linux kernel patch has been merged into the mainline.)
I will stick around the IRC channel for some time. Feel free to ask me to clarify more things if you still have questions.
- the remaining patches look okay to me, but they need testing on a
wide variety of distros to ensure there isn't a regression. I'll do that when I can, but that wont be within the next 4-6 weeks.
-Kevin
Thanks. I was hoping the patches could be accepted before I back ported them to our internal systems.
I will now just start patching our internal code. ("[PATCH v2] Use readelf -WSrs instead of objdump -thr so that llvm-readelf can be used as a replacement") I will report back if I manage to build/test things to add another data point.