On 06.11.2024 13:23, Andrew Cooper wrote:
> On 06/11/2024 11:41 am, Frediano Ziglio wrote:
>> This toolchain generates different object files.
>> Object have 3 additional sections which must be handled by the
>> linker script.
>> Added sections need to have special type so we put them in
>> separate sections as linker will copy type from input sections.
>>
>> Fixes: aa9045e77130 ('x86/boot: Rework how 32bit C is linked/included for
>> early boot')
>>
>> Signed-off-by: Frediano Ziglio <frediano.zig...@cloud.com>
>
> The patch itself is fine, but the commit message is quite stale now
> you've split the fix into 3 bits. I'd recommend:
>
> ---%<---
> x86/boot: Explicitly list .{sym,shstr,str}tab in build32.lds.S
>
> Currently, building with LLVM's LLD fails:
>
> ld -melf_i386_fbsd --orphan-handling=error -N -T ...
> ld: error: <internal>:(.symtab) is being placed in '.symtab'
> ld: error: <internal>:(.shstrtab) is being placed in '.shstrtab'
> ld: error: <internal>:(.strtab) is being placed in '.strtab'
> gmake[11]: *** [arch/x86/boot/Makefile:69:
> arch/x86/boot/built-in-32.base.bin] Error 1
>
> This is a consequence of --orphan-handling, and it appears that Binutils
> doesn't diagnose some orphaned sections even explicitly asked to do so.
With my binutils hat on, I'd like to express that I don't view this as a
fair statement. GNU ld simply doesn't extend the concept of orphaned
sections to purely control ones, which need processing / transforming in
one way or another anyway. Instead I'm puzzled by lld's behavior
requiring such sections to be named explicitly.
Jan
