[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 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
Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
|
