Re: [PATCH 2/2] xen: update CONFIG_DEBUG_INFO help text

[Jan Beulich <jbeulich@xxxxxxxx>]

On 07.03.2023 16:02, Juergen Gross wrote:
> On 07.03.23 15:34, Jan Beulich wrote:
>> On 07.03.2023 15:23, Juergen Gross wrote:
>>> On 07.03.23 15:18, Jan Beulich wrote:
>>>> On 07.03.2023 15:04, Juergen Gross wrote:
>>>>> On 07.03.23 11:41, Jan Beulich wrote:
>>>>>> On 07.03.2023 07:32, Juergen Gross wrote:
>>>>>>> --- a/xen/Kconfig.debug
>>>>>>> +++ b/xen/Kconfig.debug
>>>>>>> @@ -15,8 +15,11 @@ config DEBUG_INFO
>>>>>>>         bool "Compile Xen with debug info"
>>>>>>>         default DEBUG
>>>>>>>         ---help---
>>>>>>> -         If you say Y here the resulting Xen will include debugging 
>>>>>>> info
>>>>>>> -         resulting in a larger binary image.
>>>>>>> +         Say Y here if you want to build Xen with debug information. 
>>>>>>> This
>>>>>>> +         information is needed e.g. for doing crash dump analysis of 
>>>>>>> the
>>>>>>> +         hypervisor via the "crash" tool.
>>>>>>> +         Saying Y will increase the size of xen-syms and the built EFI
>>>>>>> +         binary.
>>>>>>
>>>>>> Largely fine with me, just one question: Why do you mention xen-syms by
>>>>>> name, but then verbally describe xen.efi? And since, unlike for xen-syms,
>>>>>
>>>>> For xen-syms I couldn't find an easily understandable wording. I'd be fine
>>>>> with just saying "xen.efi".
>>>>>
>>>>>> this affects the installed binary actually used for booting (which may
>>>>>> be placed on a space constrained partition), it may be prudent to
>>>>>> mention INSTALL_EFI_STRIP here (as a way to reduce the binary size of
>>>>>> what ends up on the EFI partition, even if that wouldn't affect the
>>>>>> "normal" way of putting the binary on the EFI partition - people would
>>>>>> still need to take care of that in their distros).
>>>>>
>>>>> What about adding a related Kconfig option instead?
>>>>
>>>> How would a Kconfig option possibly affect this? You want debug info
>>>> in the xen.efi in its standard install location (outside of the EFI
>>>> partition); or else if you don't want it there why would you want it
>>>> in xen-syms? It is the step of populating the EFI partition from the
>>>> standard install location where some equivalent of INSTALL_EFI_STRIP
>>>> would come into play. That step is done outside of Xen's build
>>>> system and hence outside of any Kconfig control.
>>>
>>> We have 2 binaries for the non-EFI hypervisor (xen-syms and xen[.gz]).
>>> Why can't we have the same for EFI? E.g. xen-syms.efi and xen.efi.
>>> The former would have the debug-info, the latter could be installed
>>> into the EFI partition.
>>
>> I view the two-binaries model of the non-EFI case as merely an
>> implementation detail;
> 
> The ability to do crash dump analysis is more than an implementation
> detail IMHO. It is a feature and as such the availability of xen-syms
> should be seen as an interface which functionality should be kept.

That you're looking the opposite way at things: The oddity is that we
can't use xen-syms directly for booting (which is also why it has this
specific name; otherwise "xen" would be what the linker produces).

>> it just so happens that there's little point
>> in mkelf32 retaining debug info. I therefore don't view it as very
>> reasonable to artificially introduce yet another binary.
> 
> In case there is no other way to enable hypervisor crash dump analysis
> I don't see this as an unreasonable approach.
> 
> It should be verified that this approach is really enabling the crash
> dump analysis of a crash dump from a xen.efi booted system, of course.

Right. First question would be whether they manage to consume Dwarf
debug info from a PE/COFF executable. Possibly the way to go is to
separate Dwarf data out of xen.efi into an ELF "container"; I have no
idea whether objcopy could be used for something like that.

Jan