Re: [PATCH for-4.22] xen/x86: Always strip xen.efi

[Frediano Ziglio <freddy77@xxxxxxxxx>]

On Tue, 16 Jun 2026 at 15:28, Frediano Ziglio <freddy77@xxxxxxxxx> wrote:
>
> On Tue, 16 Jun 2026 at 15:15, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> >
> > On 16.06.2026 16:07, Frediano Ziglio wrote:
> > > On Thu, 11 Jun 2026 at 15:42, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> > >>
> > >> On 11.06.2026 16:38, Jan Beulich wrote:
> > >>> On 08.06.2026 19:31, Andrew Cooper wrote:
> > >>>> Some old versions of binutils ld managed to produce efi files which the
> > >>>> matching version of strip couldn't process.  This includes Binutils 
> > >>>> 2.26
> > >>>> included in Ubuntu 16.04.  Delete the workaround for this bug, and 
> > >>>> require a
> > >>>> less broken toolchain.
> > >>>
> > >>> And we're certain newer versions of strip don't do any harm to the 
> > >>> binaries?
> > >>> Already towards Frediano's posting I said that having looked at how 
> > >>> things
> > >>> work there, I'm far from certain.
> > >>
> > >> I should have added: An option may be to link twice: Once with debug info
> > >> included, and once with it stripped. Personally I trust the linker 
> > >> creating
> > >> the various headers, including the section ones, more than strip's (or
> > >> objcopy's). Yet then I can only repeat my observation that linking PE+ 
> > >> from
> > >> ELF inputs looks to be significantly slower than linking ELF -> ELF.
> > >
> > > That was also attempted. See previous versions. And no, it does not work.
> >
> > How exactly does it not work? When stripping debug info while linking (as
> > we now do for the first two passes), the resulting image should be both
> > small enough and correct. What am I missing? The only caveat I'm aware of
> > is the Eclair scan, where we should avoid doing any work for the
> > "auxiliary" linking step (the one not producing the binary that's actually
> > going to be used for running Xen).
> >
> > Jan
>
> One thing I remember was the build-id was not the same and debugging
> tools could not work.
>

Another reason was that the generated binary with debug information
was not working with various tools anyway (gdb complained about it and
also binutils again for converting to ELF to use other tools like I
think live patching).
About this I'm less sure about.

Frediano