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
