| Message ID | 20241106114150.1432512-4-frediano.ziglio@cloud.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | x86/boot: Fix build with LLVM toolchain | expand |
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
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)
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(+)