Re: [PATCH 2/2] xen: update CONFIG_DEBUG_INFO help text
On 07.03.23 16:14, Jan Beulich wrote: 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. I tried: > objcopy --remove-section=.text --remove-section=.rodata --remove-section=.init.* --remove-section=.data --remove-section=.data.* --remove-section=.bss --output-target=elf64-x86-64 xen.efi xen-debug and the result was: > objdump -h xen-debug xen-debug: file format elf64-x86-64 Sections: Idx Name Size VMA LMA File off Algn 0 .buildid 0035 82d040486fb8 82d040486fb8 0fb8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .init 000a2340 82d04060 82d04060 1000 2**2 CONTENTS, ALLOC, LOAD, CODE 2 .reloc1658 82d04094d5a0 82d04094d5a0 000a35a0 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .debug_abbrev 00091f6b 82d04094ebf8 82d04094ebf8 000a4bf8 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 4 .debug_info 00fd7af4 82d0409e0b63 82d0409e0b63 00136b63 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 5 .debug_str00843395 82d0419b8657 82d0419b8657 0110e657 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 6 .debug_line 0011dba5 82d0421fb9ec 82d0421fb9ec 019519ec 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 7 .debug_frame 0003fd7c 82d042319594 82d042319594 01a6f591 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 8 .debug_loc0047fcfd 82d04
Re: [PATCH 2/2] xen: update CONFIG_DEBUG_INFO help text
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
Re: [PATCH 2/2] xen: update CONFIG_DEBUG_INFO help text
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 OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH 2/2] xen: update CONFIG_DEBUG_INFO help text
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; 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. Another thing would be if there was a way to produce a binary without debug info accompanied by a separate file holding just the debug info. Yet I'm unaware of such being possible with PE/COFF binaries. But yes - technically this might be an option (although, just to mention it, I'm having a vague recollection of there being an issue with this, but I can't say what this might be, plus it is easily possible that I'm misremembering or mixing up things). Jan
Re: [PATCH 2/2] xen: update CONFIG_DEBUG_INFO help text
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. Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH 2/2] xen: update CONFIG_DEBUG_INFO help text
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. Jan > I'd be fine with a textual mentioning of INSTALL_EFI_STRIP, too. > >> I guess this size aspect wrt the EFI partition is actually something >> that should also be mentioned in patch 1, because this can be an argument >> against exposure of the option (precisely because it requires extra >> activity to prevent the EFI partition running out of space). > > This might be another reason to make it easily configurable. > > > Juergen
Re: [PATCH 2/2] xen: update CONFIG_DEBUG_INFO help text
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? I'd be fine with a textual mentioning of INSTALL_EFI_STRIP, too. I guess this size aspect wrt the EFI partition is actually something that should also be mentioned in patch 1, because this can be an argument against exposure of the option (precisely because it requires extra activity to prevent the EFI partition running out of space). This might be another reason to make it easily configurable. Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH 2/2] xen: update CONFIG_DEBUG_INFO help text
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, 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). I guess this size aspect wrt the EFI partition is actually something that should also be mentioned in patch 1, because this can be an argument against exposure of the option (precisely because it requires extra activity to prevent the EFI partition running out of space). Jan
[PATCH 2/2] xen: update CONFIG_DEBUG_INFO help text
Update the help text of the CONFIG_DEBUG_INFO option to be a little bit more specific. Signed-off-by: Juergen Gross --- xen/Kconfig.debug | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug index a2691f4239..20c73ee55a 100644 --- 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. if DEBUG || EXPERT -- 2.35.3
