Re: [PATCH v2] xen: Strip xen.efi by default

[Jan Beulich <jbeulich@xxxxxxxx>]

On 07.10.2025 16:23, Marek Marczykowski-Górecki wrote:
> On Tue, Oct 07, 2025 at 04:12:13PM +0200, Jan Beulich wrote:
>> On 02.10.2025 16:10, Marek Marczykowski-Górecki wrote:
>>> On Thu, Oct 02, 2025 at 02:05:56PM +0100, Andrew Cooper wrote:
>>>> On 12/06/2025 11:07 am, Frediano Ziglio wrote:
>>>>> For xen.gz file we strip all symbols and have an additional
>>>>> xen-syms file version with all symbols.
>>>>> Make xen.efi more coherent stripping all symbols too.
>>>>> xen.efi.elf can be used for debugging.
>>>>>
>>>>> Signed-off-by: Frediano Ziglio <frediano.ziglio@xxxxxxxxx>
>>>
>>> Generally,
>>> Reviewed-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
>>
>> Just to double check: You offer this after having read (and discarded) my
>> comments on v1, which v2 left largely unaddressed? 
> 
> You mean the one about objcopy result used for debugging? I didn't see
> that before, since I wasn't in cc on v1... 
> 
> Anyway, are you aware of some specific objcopy issue. Or in other words:
> would xen.efi.elf _currently_ be broken (as in - unusable for
> debugging/disassembly)?

I can't tell. I've seen fair parts of the code in the course of addressing
various issues, and I would be very surprised if all of that was working
correctly.

> If not, then I take that relevant part of your
> objection is mostly about inconsistent naming (xen.gz -> xen-syms, vs
> xen.efi -> xen.efi.elf). Would xen-syms.efi.elf be better?

Plus the one asking to strip only debug info, but not the symbol table.
(And no, none of the suggested names look really nice to me.)

Plus the one indicating that the change better wouldn't be made in the
first place. As said, to deal with size issues we already have machinery
in place. Not very nice machinery, but it's apparently functioning.

For context, and to avoid the argument that GNU objcopy and strip are
built from the same source file: The objcopy invocation here is to alter
the format, whereas the strip invocation is merely to remove data without
changing the format. The weakness in binutils, to a fair part due to a
lack of routine testing, is with format conversions. (And yes, routine
testing, as nice as it would be to have such, doesn't fit very well with
how testing overall works, as commonly only the default format of a
particular target would be tested.)

Jan