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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 06.11.2024 12:58, Frediano Ziglio wrote:
> On Wed, Nov 6, 2024 at 11:45 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>
>> On 06.11.2024 12:34, Frediano Ziglio wrote:
>>> On Wed, Nov 6, 2024 at 10:59 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>>>
>>>> On 06.11.2024 07:56, Frediano Ziglio wrote:
>>>>> On Tue, Nov 5, 2024 at 5:06 PM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>>>>>
>>>>>> On 05.11.2024 17:35, Frediano Ziglio wrote:
>>>>>>> On Tue, Nov 5, 2024 at 3:32 PM Jan Beulich <jbeulich@xxxxxxxx> 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?
> 
> $ 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.

Just to mention it here as well - objdump's -x option doesn't include "control"
sections. Considering the help text for -x this feels like a bug. However, as
documentation has it:

"Display all available header information, including the symbol table and
 relocation entries."

the symbol table and possible relocations _are_ being displayed, just not as
part of "Sections:".

Jan