On 2020-04-16, Kevin O'Connor wrote:
On Tue, Apr 14, 2020 at 12:07:54PM -0700, Fāng-ruì Sòng
On Mon, Apr 6, 2020 at 5:55 PM Fangrui Song
> This patch series make seabios linkable with lld.
"[PATCH v2] Use readelf -WSrs instead of objdump -thr so that
llvm-readelf can be used as a replacement"
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
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.
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.