Re: [Xen-devel] [PATCH] x86/boot: fix build with certain older gcc versions

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Fri, Dec 16, 2016 at 05:38:35AM -0700, Jan Beulich wrote:
> >>> On 16.12.16 at 11:33, <daniel.kiper@xxxxxxxxxx> wrote:
> > On Thu, Dec 15, 2016 at 07:04:51AM -0700, Jan Beulich wrote:
> >> Despite all attempts so far (ending in commit fecf584294 ["Config.mk:
> >> fix comment for debug option"] adjusting the respective comment),
> >> Config.mk's debug= setting still affects the hypervisor build: CFLAGS
> >> gets -g added there.
> >>
> >> xen/arch/x86/boot/build32.mk includes that file, and hence inherits the
> >> setting too. Some gcc versions take -g to create an .eh_frame section
> >> despite -fno-asynchronous-unwind-tables (which instead one would expect
> >> to produce .debug_frame).
> >
> > Hmmm... Smells like a bug...
>
> Possibly - I have no idea what the formal spec of linker behavior
> here is (assuming there is one anywhere, which I doubt).

:-)))

> >> In turn, commit 93c0c0287a ("x86/boot: create *.lnk files with linker
> >> script") was - in my understanding - supposed to make sure .text is
> >> first, but apparently it did also not really achieve that effect: Both
> >
> > The main goal was to have text and data sections merged into one text
> > section.
> >
> >> reloc.lnk and reloc.bin in the case here ended up with .eh_frame first,
> >> which obviously rendered the whole final binary unusable.
> >
> > Should not we discard unneeded sections in build32.lds? It looks a bit
> > more complicated but maybe we should consider such option too.
>
> Hmm - would you mean a wholesale *(*) pattern to be used here?

I was thinking about discarding specific sections which are known to do harm.

> I think this whole keep-some-discard-some approach is rather
> fragile, not matter how much we customize it.

That is why I am not convinced that we should do that. I just wanted
to be sure that this option was considered too. So, I agree that -g0
approach is better. However, I think that we should replace -g% with
-g0 as I said in my earlier email.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel