| Message ID | 20230307063214.30569-3-jgross@suse.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | xen: some CONFIG_DEBUG_INFO changes | expand |
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
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
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
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
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
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
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
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 00000035 ffff82d040486fb8 ffff82d040486fb8 00000fb8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .init 000a2340 ffff82d040600000 ffff82d040600000 00001000 2**2 CONTENTS, ALLOC, LOAD, CODE 2 .reloc 00001658 ffff82d04094d5a0 ffff82d04094d5a0 000a35a0 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .debug_abbrev 00091f6b ffff82d04094ebf8 ffff82d04094ebf8 000a4bf8 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 4 .debug_info 00fd7af4 ffff82d0409e0b63 ffff82d0409e0b63 00136b63 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 5 .debug_str 00843395 ffff82d0419b8657 ffff82d0419b8657 0110e657 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 6 .debug_line 0011dba5 ffff82d0421fb9ec ffff82d0421fb9ec 019519ec 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 7 .debug_frame 0003fd7c ffff82d042319594 ffff82d042319594 01a6f591 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 8 .debug_loc 0047fcfd ffff82d042359310 ffff82d042359310 01aaf30d 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 9 .debug_ranges 000d2650 ffff82d0427d9010 ffff82d0427d9010 01f2f00a 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 10 .debug_aranges 00015bd0 ffff82d0428ab660 ffff82d0428ab660 0200165a 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS This seems to be a reasonable output. Whether crash is happy with that file is another question, of course. Juergen
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
Update the help text of the CONFIG_DEBUG_INFO option to be a little bit more specific. Signed-off-by: Juergen Gross <jgross@suse.com> --- xen/Kconfig.debug | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)