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

[Juergen Gross <jgross@xxxxxxxx>]

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.

> 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.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature