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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 17.06.2026 14:07, Marek Marczykowski-Górecki wrote:
> 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,

Indeed, as it would further undermine reproducible builds. That said, we
could certainly put some (a lot of?) sanity checking in place.

> it doesn't matter with strip
> approach (used by virtually every other project I've seen).

Yet I expect that's "strip" on ELF binaries, not PE ones?

Jan