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

[Frediano Ziglio <freddy77@xxxxxxxxx>]

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.

Frediano