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@cloud.com>
---
 xen/arch/x86/boot/build32.lds.S | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/xen/arch/x86/boot/build32.lds.S b/xen/arch/x86/boot/build32.lds.S
index 9b29f0184f..1e59732edd 100644
--- a/xen/arch/x86/boot/build32.lds.S
+++ b/xen/arch/x86/boot/build32.lds.S
@@ -66,6 +66,15 @@ SECTIONS
        *(.comment.*)
        *(.note.*)
   }
+  .shstrtab : {
+       *(.shstrtab)
+  }
+  .strtab : {
+       *(.strtab)
+  }
+  .symtab : {
+       *(.symtab)
+  }
   /* Dynamic linkage sections.  Collected simply so we can check they're empty. */
   .got : {
         *(.got)
-- 
2.34.1

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

List the sections explicitly.

Fixes ...
---%<---

Happy to fix on commit.

~Andrew

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@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