[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

I checked the object files and there are no such sections using GNU toolchain.

Frediano



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.