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

["Roger Pau Monné" <roger.pau@citrix.com>]

On Wed, Nov 06, 2024 at 11:58:19AM +0000, Frediano Ziglio wrote:
> On Wed, Nov 6, 2024 at 11:45 AM Jan Beulich <jbeulich@suse.com> wrote:
> >
> > On 06.11.2024 12:34, Frediano Ziglio wrote:
> > > On Wed, Nov 6, 2024 at 10:59 AM Jan Beulich <jbeulich@suse.com> wrote:
> > >>
> > >> On 06.11.2024 07:56, Frediano Ziglio wrote:
> > >>> On Tue, Nov 5, 2024 at 5:06 PM Jan Beulich <jbeulich@suse.com> wrote:
> > >>>>
> > >>>> On 05.11.2024 17:35, Frediano Ziglio wrote:
> > >>>>> On Tue, Nov 5, 2024 at 3:32 PM Jan Beulich <jbeulich@suse.com> wrote:
> > >>>>>>
> > >>>>>> On 05.11.2024 15:55, Frediano Ziglio wrote:
> > >>>>>>> This toolchain generates different object and map files.
> > >>>>>>> Account for these changes.
> > >>>>>>
> > >>>>>> At least briefly mentioning what exactly the differences are would be
> > >>>>>> quite nice, imo.
> > >>>>>>
> > >>>>>
> > >>>>> What about.
> > >>>>>
> > >>>>> Object have 3 additional sections which must be handled by the linker script.
> > >>>>
> > >>>> I expect these sections are there in both cases. The difference, I assume,
> > >>>> is that for the GNU linker they don't need mentioning in the linker script.
> > >>>> Maybe that's what you mean to say, but to me at least the sentence can also
> > >>>> be interpreted differently.
> > >>>
> > >>> Why do you expect such sections? They are used for dynamic symbols in
> > >>> shared objects, we don't use shared objects here. Normal object
> > >>> symbols are not handled by these sections. GNU compiler+linker (we
> > >>> link multiple objects together) do not generate these sections. So the
> > >>> comment looks correct to me.
> > >>
> > >> About every ELF object will have .symtab and .strtab, and many also a
> > >> separate .shstrtab. There's nothing "dynamic" about them. IOW - I'm
> > >> confused by your reply.
> > >
> > > I checked the object files and there are no such sections using GNU toolchain.
> >
> > I think I checked every *.o that's under boot/, and they all have these three
> > sections. Can you clarify which one(s) specifically you checked?
> >
> > Jan
> 
> $ gcc --version
> gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
> Copyright (C) 2021 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> $ ld --version
> GNU ld (GNU Binutils for Ubuntu) 2.38
> Copyright (C) 2022 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public Licence version 3 or (at your option) a later version.
> This program has absolutely no warranty.
> 
> $ find xen/normal/ xen/pvh/ -name \*.o | xargs -ifilename sh -c
> 'objdump -x filename' | grep -e \\.
> shstrtab -e \\.strtab -e \\.symtab
> 
> (xen/normal and xen/pvh are the build directory, with different configurations)
> 
> I'm saying that's possibly why the linker scripts didn't need to
> specify these sections.

objdump -x doesn't seem to list .symtab, .strtab or .shstrtab, but
readelf -S does:

# readelf -SW xen/arch/x86/boot/reloc.o
[...]
  [11] .symtab           SYMTAB          00000000 0004b0 000190 10     12  21  4
  [12] .strtab           STRTAB          00000000 000640 000092 00      0   0  1
  [13] .shstrtab         STRTAB          00000000 000734 000078 00      0   0  1

# objdump -x xen/arch/x86/boot/reloc.o
[...]
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .group        00000008  00000000  00000000  00000034  2**2
                  CONTENTS, READONLY, GROUP, LINK_ONCE_DISCARD
  1 .text         0000041d  00000000  00000000  00000040  2**4
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  2 .data         00000000  00000000  00000000  0000045d  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          00000000  00000000  00000000  0000045d  2**0
                  ALLOC
  4 .rodata       00000024  00000000  00000000  00000460  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
  5 .text.__x86.get_pc_thunk.bx 00000004  00000000  00000000  00000484  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  6 .comment      00000028  00000000  00000000  00000488  2**0
                  CONTENTS, READONLY
  7 .note.GNU-stack 00000000  00000000  00000000  000004b0  2**0
                  CONTENTS, READONLY

It also seems to skip .rel sections.  It doesn't seem reliable to use
objdump to get ELF sections.

Regards, Roger.