Re: [PATCH v2 3/3] x86/boot: Fix build with LLVM toolchain

[Jan Beulich <jbeulich@xxxxxxxx>]

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.ziglio@xxxxxxxxx>
> 
> 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