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

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

On Wed, Jun 17, 2026 at 01:55:59PM +0200, Jan Beulich wrote:
> On 16.06.2026 16:28, Frediano Ziglio 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).
> > 
> > One thing I remember was the build-id was not the same and debugging
> > tools could not work.
> 
> Hmm, yes, that's a little ugly, but can likely be dealt with by using
> --build-id=0x<hexdigits> to replicate the build-id that was generated for
> the main binary.

IMO linking twice (with and without debug symbols) has a great risk
potential of producing different layout of the binary. While arguably it
would be a bug in the build scripts, it doesn't matter with strip
approach (used by virtually every other project I've seen).

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

Attachment: signature.asc
Description: PGP signature