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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 11.06.2025 12:49, Frediano Ziglio wrote:
> On Wed, Jun 11, 2025 at 10:35 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>
>> On 10.06.2025 12:12, 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.
>>
>> And the other difference (compressed vs not) still remains.
>>
>>> xen.efi.elf can be used for debugging.
>>
>> Hmm, that's the result of ...
>>
>>> --- a/xen/arch/x86/Makefile
>>> +++ b/xen/arch/x86/Makefile
>>> @@ -238,6 +238,7 @@ endif
>>>               > $@.map
>>>  ifeq ($(CONFIG_DEBUG_INFO),y)
>>>       $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O 
>>> elf64-x86-64 $@ $@.elf
>>> +     $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(STRIP) $@
>>>  endif
>>>       rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
>>>  ifeq ($(CONFIG_XEN_IBT),y)
>>
>> ... objcopy. Having looked at the involved code in that utility, I mistrust 
>> its
>> output from such a conversion to really be an exact representation of the 
>> input.
> 
> From 
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;f=xen/arch/x86/Makefile;h=f514bab30ef8d4ade77a27c926e283c9bbbf9ffd,
> 
>     Today it is not possible to analyse crash dumps of a system in
>     hypervisor mode when it had been booted via EFI, as the crash utility
>     doesn't understand the file format of xen.efi.
> 
>     This can easily be solved by creating an ELF file from xen.efi via
>     objcopy. Using that file as name list for crash enables the user to
>     analyse the dump in hypervisor mode. Note that crash isn't happy with
>     a file containing no text and data, so using --only-keep-debug is not
>     an option.
> 
> Isn't that true anymore?

That's likely as true as before - heavily depending on objcopy not screwing up.
I don't think any thorough analysis was done back when that commit was put
together.

>> IOW I'd much rather use the original file. As a possible compromise, could we
>> perhaps merely strip debug info, but retain the symbol table, matching the
>> prior default for $(efi-strip-opt)?
> 
> Not clear the compromise you are intending here, the debug file has
> all information available, why do you need an intermediate one? We
> strip everything for ELF, why not be coherent?

If I want to e.g. see the disassembly of xen.efi, I find it heavily misleading
that I then would have to disassemble xen.efi.elf instead. One can get used to
it, sure. But for xen.gz / xen-syms it just was that way from the very
beginning (plus it's kind of obvious that a *.gz file cannot directly be
disassembled anyway). And for disassembly, the loss of debug info is far less
impactful than the loss of the symbol table. (Hence also why only debug info
was being stripped during installation so far.)

Jan