* [PATCH 0/2] xen: some CONFIG_DEBUG_INFO changes
@ 2023-03-07 6:32 Juergen Gross
2023-03-07 6:32 ` [PATCH 1/2] xen: move CONFIG_DEBUG_INFO out of EXPERT section Juergen Gross
2023-03-07 6:32 ` [PATCH 2/2] xen: update CONFIG_DEBUG_INFO help text Juergen Gross
0 siblings, 2 replies; 16+ messages in thread
From: Juergen Gross @ 2023-03-07 6:32 UTC (permalink / raw
To: xen-devel
Cc: Juergen Gross, Andrew Cooper, George Dunlap, Jan Beulich,
Julien Grall, Stefano Stabellini, Wei Liu
Enabling crash dump analysis of the hypervisor requires the hypervisor
having been built with CONFIG_DEBUG_INFO enabled. Today this requires
either CONFIG_DEBUG or CONFIG_EXPERT set, which are both not security
supported.
This small series changes that in order to allow security supported
Xen builds with the capability to do crash dump analysis via the
"crash" tool.
Juergen Gross (2):
xen: move CONFIG_DEBUG_INFO out of EXPERT section
xen: update CONFIG_DEBUG_INFO help text
xen/Kconfig.debug | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
--
2.35.3
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 1/2] xen: move CONFIG_DEBUG_INFO out of EXPERT section
2023-03-07 6:32 [PATCH 0/2] xen: some CONFIG_DEBUG_INFO changes Juergen Gross
@ 2023-03-07 6:32 ` Juergen Gross
2023-03-07 10:31 ` Jan Beulich
2023-03-07 6:32 ` [PATCH 2/2] xen: update CONFIG_DEBUG_INFO help text Juergen Gross
1 sibling, 1 reply; 16+ messages in thread
From: Juergen Gross @ 2023-03-07 6:32 UTC (permalink / raw
To: xen-devel
Cc: Juergen Gross, Andrew Cooper, George Dunlap, Jan Beulich,
Julien Grall, Stefano Stabellini, Wei Liu
In order to support hypervisor analysis of crash dumps, xen-syms needs
to contain debug_info. It should be allowed to configure the hypervisor
to be built with CONFIG_DEBUG_INFO in non-debug builds without having
to enable EXPERT.
Using a rather oldish gcc (7.5) it was verified that code generation
doesn't really differ between CONFIG_DEBUG_INFO on or off without
CONFIG_DEBUG being set (only observed differences were slightly
different symbol addresses, verified via "objdump -d"). The old gcc
version selection was based on the assumption, that newer gcc won't
regress in this regard.
So move CONFIG_DEBUG_INFO out of the section guarded by EXPERT.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
xen/Kconfig.debug | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index fad3050d4f..a2691f4239 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -11,6 +11,13 @@ config DEBUG
You probably want to say 'N' here.
+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.
+
if DEBUG || EXPERT
config CRASH_DEBUG
@@ -28,13 +35,6 @@ config GDBSX
If you want to enable support for debugging guests from dom0 via
gdbsx then say Y.
-config DEBUG_INFO
- bool "Compile Xen with debug info"
- default y
- ---help---
- If you say Y here the resulting Xen will include debugging info
- resulting in a larger binary image.
-
config FRAME_POINTER
bool "Compile Xen with frame pointers"
default DEBUG
--
2.35.3
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH 2/2] xen: update CONFIG_DEBUG_INFO help text
2023-03-07 6:32 [PATCH 0/2] xen: some CONFIG_DEBUG_INFO changes Juergen Gross
2023-03-07 6:32 ` [PATCH 1/2] xen: move CONFIG_DEBUG_INFO out of EXPERT section Juergen Gross
@ 2023-03-07 6:32 ` Juergen Gross
2023-03-07 10:41 ` Jan Beulich
1 sibling, 1 reply; 16+ messages in thread
From: Juergen Gross @ 2023-03-07 6:32 UTC (permalink / raw
To: xen-devel
Cc: Juergen Gross, Andrew Cooper, George Dunlap, Jan Beulich,
Julien Grall, Stefano Stabellini, Wei Liu
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(-)
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
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH 1/2] xen: move CONFIG_DEBUG_INFO out of EXPERT section
2023-03-07 6:32 ` [PATCH 1/2] xen: move CONFIG_DEBUG_INFO out of EXPERT section Juergen Gross
@ 2023-03-07 10:31 ` Jan Beulich
2023-03-07 11:33 ` Juergen Gross
0 siblings, 1 reply; 16+ messages in thread
From: Jan Beulich @ 2023-03-07 10:31 UTC (permalink / raw
To: Juergen Gross
Cc: Andrew Cooper, George Dunlap, Julien Grall, Stefano Stabellini,
Wei Liu, xen-devel
On 07.03.2023 07:32, Juergen Gross wrote:
> In order to support hypervisor analysis of crash dumps, xen-syms needs
> to contain debug_info. It should be allowed to configure the hypervisor
> to be built with CONFIG_DEBUG_INFO in non-debug builds without having
> to enable EXPERT.
In how far does this apply to xen.efi as well? (You can't really use
xen-syms for crash debugging when the crash occurred with xen.efi in
use.)
> Using a rather oldish gcc (7.5) it was verified that code generation
> doesn't really differ between CONFIG_DEBUG_INFO on or off without
> CONFIG_DEBUG being set (only observed differences were slightly
> different symbol addresses, verified via "objdump -d"). The old gcc
> version selection was based on the assumption, that newer gcc won't
> regress in this regard.
This is good to know, but I'm still curious about the mentioned
differences in symbol addresses: If code generation didn't change, what
caused addresses to differ? Is that merely because individual functions
or objects are emitted in different order by the compiler? (If so I'd
be inclined to infer that comparing generated code must have been
quite a bit of effort, as first of all you would have had to undo that
re-ordering.)
The other thing to at least mention here is that with new enough
binutils, when Dwarf debug info can be enabled for keeping in xen.efi,
linking time of xen.efi increases quite a bit with DEBUG_INFO=y (which
is a result of linking ELF objects into a non-ELF binary, when at
least GNU ld optimizes only the ELF -> ELF case when processing the
[massive amount of] relocations).
> So move CONFIG_DEBUG_INFO out of the section guarded by EXPERT.
Isn't the prior DEBUG dependency as relevant?
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -11,6 +11,13 @@ config DEBUG
>
> You probably want to say 'N' here.
>
> +config DEBUG_INFO
> + bool "Compile Xen with debug info"
> + default DEBUG
> + ---help---
Nit: Even if just code movement, please use "help" in the moved
instance.
> + If you say Y here the resulting Xen will include debugging info
> + resulting in a larger binary image.
> +
> if DEBUG || EXPERT
The new placement isn't very helpful when considering some of the ways
kconfig data is presented. At least for the non-graphical presentation
it used to be the case that hierarchies were presented properly only
when dependencies immediately followed their dependents (i.e. here:
DEBUG is a dependent of everything inside the "if" above). Therefore I
think rather than moving the block up you may better move it down past
the "endif".
Jan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/2] xen: update CONFIG_DEBUG_INFO help text
2023-03-07 6:32 ` [PATCH 2/2] xen: update CONFIG_DEBUG_INFO help text Juergen Gross
@ 2023-03-07 10:41 ` Jan Beulich
2023-03-07 14:04 ` Juergen Gross
0 siblings, 1 reply; 16+ messages in thread
From: Jan Beulich @ 2023-03-07 10:41 UTC (permalink / raw
To: Juergen Gross
Cc: Andrew Cooper, George Dunlap, Julien Grall, Stefano Stabellini,
Wei Liu, xen-devel
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/2] xen: move CONFIG_DEBUG_INFO out of EXPERT section
2023-03-07 10:31 ` Jan Beulich
@ 2023-03-07 11:33 ` Juergen Gross
2023-03-07 11:42 ` Jan Beulich
0 siblings, 1 reply; 16+ messages in thread
From: Juergen Gross @ 2023-03-07 11:33 UTC (permalink / raw
To: Jan Beulich
Cc: Andrew Cooper, George Dunlap, Julien Grall, Stefano Stabellini,
Wei Liu, xen-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 3191 bytes --]
On 07.03.23 11:31, Jan Beulich wrote:
> On 07.03.2023 07:32, Juergen Gross wrote:
>> In order to support hypervisor analysis of crash dumps, xen-syms needs
>> to contain debug_info. It should be allowed to configure the hypervisor
>> to be built with CONFIG_DEBUG_INFO in non-debug builds without having
>> to enable EXPERT.
>
> In how far does this apply to xen.efi as well? (You can't really use
> xen-syms for crash debugging when the crash occurred with xen.efi in
> use.)
TBH I don't know what is needed for analysis of crash dumps with the xen.efi
binary.
>
>> Using a rather oldish gcc (7.5) it was verified that code generation
>> doesn't really differ between CONFIG_DEBUG_INFO on or off without
>> CONFIG_DEBUG being set (only observed differences were slightly
>> different symbol addresses, verified via "objdump -d"). The old gcc
>> version selection was based on the assumption, that newer gcc won't
>> regress in this regard.
>
> This is good to know, but I'm still curious about the mentioned
> differences in symbol addresses: If code generation didn't change, what
> caused addresses to differ? Is that merely because individual functions
> or objects are emitted in different order by the compiler? (If so I'd
> be inclined to infer that comparing generated code must have been
> quite a bit of effort, as first of all you would have had to undo that
> re-ordering.)
I did a simple diff of the two disassembly outputs and got only small
differences for %rip relative addresses (the differences were in the
range of +/- 32 bytes).
> The other thing to at least mention here is that with new enough
> binutils, when Dwarf debug info can be enabled for keeping in xen.efi,
> linking time of xen.efi increases quite a bit with DEBUG_INFO=y (which
> is a result of linking ELF objects into a non-ELF binary, when at
> least GNU ld optimizes only the ELF -> ELF case when processing the
> [massive amount of] relocations).
Okay, I can add this.
>
>> So move CONFIG_DEBUG_INFO out of the section guarded by EXPERT.
>
> Isn't the prior DEBUG dependency as relevant?
Not for the case "non-debug builds" the patch is addressing.
>
>> --- a/xen/Kconfig.debug
>> +++ b/xen/Kconfig.debug
>> @@ -11,6 +11,13 @@ config DEBUG
>>
>> You probably want to say 'N' here.
>>
>> +config DEBUG_INFO
>> + bool "Compile Xen with debug info"
>> + default DEBUG
>> + ---help---
>
> Nit: Even if just code movement, please use "help" in the moved
> instance.
Okay.
>
>> + If you say Y here the resulting Xen will include debugging info
>> + resulting in a larger binary image.
>> +
>> if DEBUG || EXPERT
>
> The new placement isn't very helpful when considering some of the ways
> kconfig data is presented. At least for the non-graphical presentation
> it used to be the case that hierarchies were presented properly only
> when dependencies immediately followed their dependents (i.e. here:
> DEBUG is a dependent of everything inside the "if" above). Therefore I
> think rather than moving the block up you may better move it down past
> the "endif".
Fine with me.
Juergen
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/2] xen: move CONFIG_DEBUG_INFO out of EXPERT section
2023-03-07 11:33 ` Juergen Gross
@ 2023-03-07 11:42 ` Jan Beulich
2023-03-07 12:04 ` Juergen Gross
0 siblings, 1 reply; 16+ messages in thread
From: Jan Beulich @ 2023-03-07 11:42 UTC (permalink / raw
To: Juergen Gross
Cc: Andrew Cooper, George Dunlap, Julien Grall, Stefano Stabellini,
Wei Liu, xen-devel
On 07.03.2023 12:33, Juergen Gross wrote:
> On 07.03.23 11:31, Jan Beulich wrote:
>> On 07.03.2023 07:32, Juergen Gross wrote:
>>> Using a rather oldish gcc (7.5) it was verified that code generation
>>> doesn't really differ between CONFIG_DEBUG_INFO on or off without
>>> CONFIG_DEBUG being set (only observed differences were slightly
>>> different symbol addresses, verified via "objdump -d"). The old gcc
>>> version selection was based on the assumption, that newer gcc won't
>>> regress in this regard.
>>
>> This is good to know, but I'm still curious about the mentioned
>> differences in symbol addresses: If code generation didn't change, what
>> caused addresses to differ? Is that merely because individual functions
>> or objects are emitted in different order by the compiler? (If so I'd
>> be inclined to infer that comparing generated code must have been
>> quite a bit of effort, as first of all you would have had to undo that
>> re-ordering.)
>
> I did a simple diff of the two disassembly outputs and got only small
> differences for %rip relative addresses (the differences were in the
> range of +/- 32 bytes).
That's still odd and hence imo wants understanding. Do you still have
both binaries around?
Jan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/2] xen: move CONFIG_DEBUG_INFO out of EXPERT section
2023-03-07 11:42 ` Jan Beulich
@ 2023-03-07 12:04 ` Juergen Gross
2023-03-07 12:45 ` Jan Beulich
0 siblings, 1 reply; 16+ messages in thread
From: Juergen Gross @ 2023-03-07 12:04 UTC (permalink / raw
To: Jan Beulich
Cc: Andrew Cooper, George Dunlap, Julien Grall, Stefano Stabellini,
Wei Liu, xen-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 1639 bytes --]
On 07.03.23 12:42, Jan Beulich wrote:
> On 07.03.2023 12:33, Juergen Gross wrote:
>> On 07.03.23 11:31, Jan Beulich wrote:
>>> On 07.03.2023 07:32, Juergen Gross wrote:
>>>> Using a rather oldish gcc (7.5) it was verified that code generation
>>>> doesn't really differ between CONFIG_DEBUG_INFO on or off without
>>>> CONFIG_DEBUG being set (only observed differences were slightly
>>>> different symbol addresses, verified via "objdump -d"). The old gcc
>>>> version selection was based on the assumption, that newer gcc won't
>>>> regress in this regard.
>>>
>>> This is good to know, but I'm still curious about the mentioned
>>> differences in symbol addresses: If code generation didn't change, what
>>> caused addresses to differ? Is that merely because individual functions
>>> or objects are emitted in different order by the compiler? (If so I'd
>>> be inclined to infer that comparing generated code must have been
>>> quite a bit of effort, as first of all you would have had to undo that
>>> re-ordering.)
>>
>> I did a simple diff of the two disassembly outputs and got only small
>> differences for %rip relative addresses (the differences were in the
>> range of +/- 32 bytes).
>
> That's still odd and hence imo wants understanding. Do you still have
> both binaries around?
I have just regenerated the one with debug-info. It is a 4.17 build.
I just found the at least one reason: xen_config_data has a different size
(obviously!) and this finally leads to an offset of 32 bytes for symbols
at higher addresses (with some items only differing by 8 bytes due to
alignment).
Juergen
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/2] xen: move CONFIG_DEBUG_INFO out of EXPERT section
2023-03-07 12:04 ` Juergen Gross
@ 2023-03-07 12:45 ` Jan Beulich
0 siblings, 0 replies; 16+ messages in thread
From: Jan Beulich @ 2023-03-07 12:45 UTC (permalink / raw
To: Juergen Gross
Cc: Andrew Cooper, George Dunlap, Julien Grall, Stefano Stabellini,
Wei Liu, xen-devel
On 07.03.2023 13:04, Juergen Gross wrote:
> On 07.03.23 12:42, Jan Beulich wrote:
>> On 07.03.2023 12:33, Juergen Gross wrote:
>>> On 07.03.23 11:31, Jan Beulich wrote:
>>>> On 07.03.2023 07:32, Juergen Gross wrote:
>>>>> Using a rather oldish gcc (7.5) it was verified that code generation
>>>>> doesn't really differ between CONFIG_DEBUG_INFO on or off without
>>>>> CONFIG_DEBUG being set (only observed differences were slightly
>>>>> different symbol addresses, verified via "objdump -d"). The old gcc
>>>>> version selection was based on the assumption, that newer gcc won't
>>>>> regress in this regard.
>>>>
>>>> This is good to know, but I'm still curious about the mentioned
>>>> differences in symbol addresses: If code generation didn't change, what
>>>> caused addresses to differ? Is that merely because individual functions
>>>> or objects are emitted in different order by the compiler? (If so I'd
>>>> be inclined to infer that comparing generated code must have been
>>>> quite a bit of effort, as first of all you would have had to undo that
>>>> re-ordering.)
>>>
>>> I did a simple diff of the two disassembly outputs and got only small
>>> differences for %rip relative addresses (the differences were in the
>>> range of +/- 32 bytes).
>>
>> That's still odd and hence imo wants understanding. Do you still have
>> both binaries around?
>
> I have just regenerated the one with debug-info. It is a 4.17 build.
>
> I just found the at least one reason: xen_config_data has a different size
> (obviously!) and this finally leads to an offset of 32 bytes for symbols
> at higher addresses (with some items only differing by 8 bytes due to
> alignment).
Thanks for checking - this kind of a delta is of course to be expected.
Jan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/2] xen: update CONFIG_DEBUG_INFO help text
2023-03-07 10:41 ` Jan Beulich
@ 2023-03-07 14:04 ` Juergen Gross
2023-03-07 14:18 ` Jan Beulich
0 siblings, 1 reply; 16+ messages in thread
From: Juergen Gross @ 2023-03-07 14:04 UTC (permalink / raw
To: Jan Beulich
Cc: Andrew Cooper, George Dunlap, Julien Grall, Stefano Stabellini,
Wei Liu, xen-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 1816 bytes --]
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
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/2] xen: update CONFIG_DEBUG_INFO help text
2023-03-07 14:04 ` Juergen Gross
@ 2023-03-07 14:18 ` Jan Beulich
2023-03-07 14:23 ` Juergen Gross
0 siblings, 1 reply; 16+ messages in thread
From: Jan Beulich @ 2023-03-07 14:18 UTC (permalink / raw
To: Juergen Gross
Cc: Andrew Cooper, George Dunlap, Julien Grall, Stefano Stabellini,
Wei Liu, xen-devel
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/2] xen: update CONFIG_DEBUG_INFO help text
2023-03-07 14:18 ` Jan Beulich
@ 2023-03-07 14:23 ` Juergen Gross
2023-03-07 14:34 ` Jan Beulich
0 siblings, 1 reply; 16+ messages in thread
From: Juergen Gross @ 2023-03-07 14:23 UTC (permalink / raw
To: Jan Beulich
Cc: Andrew Cooper, George Dunlap, Julien Grall, Stefano Stabellini,
Wei Liu, xen-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 2265 bytes --]
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
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/2] xen: update CONFIG_DEBUG_INFO help text
2023-03-07 14:23 ` Juergen Gross
@ 2023-03-07 14:34 ` Jan Beulich
2023-03-07 15:02 ` Juergen Gross
0 siblings, 1 reply; 16+ messages in thread
From: Jan Beulich @ 2023-03-07 14:34 UTC (permalink / raw
To: Juergen Gross
Cc: Andrew Cooper, George Dunlap, Julien Grall, Stefano Stabellini,
Wei Liu, xen-devel
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/2] xen: update CONFIG_DEBUG_INFO help text
2023-03-07 14:34 ` Jan Beulich
@ 2023-03-07 15:02 ` Juergen Gross
2023-03-07 15:14 ` Jan Beulich
0 siblings, 1 reply; 16+ messages in thread
From: Juergen Gross @ 2023-03-07 15:02 UTC (permalink / raw
To: Jan Beulich
Cc: Andrew Cooper, George Dunlap, Julien Grall, Stefano Stabellini,
Wei Liu, xen-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 3199 bytes --]
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 #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/2] xen: update CONFIG_DEBUG_INFO help text
2023-03-07 15:02 ` Juergen Gross
@ 2023-03-07 15:14 ` Jan Beulich
2023-03-07 15:51 ` Juergen Gross
0 siblings, 1 reply; 16+ messages in thread
From: Jan Beulich @ 2023-03-07 15:14 UTC (permalink / raw
To: Juergen Gross
Cc: Andrew Cooper, George Dunlap, Julien Grall, Stefano Stabellini,
Wei Liu, xen-devel
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/2] xen: update CONFIG_DEBUG_INFO help text
2023-03-07 15:14 ` Jan Beulich
@ 2023-03-07 15:51 ` Juergen Gross
0 siblings, 0 replies; 16+ messages in thread
From: Juergen Gross @ 2023-03-07 15:51 UTC (permalink / raw
To: Jan Beulich
Cc: Andrew Cooper, George Dunlap, Julien Grall, Stefano Stabellini,
Wei Liu, xen-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 5961 bytes --]
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 #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2023-03-07 15:51 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-03-07 6:32 [PATCH 0/2] xen: some CONFIG_DEBUG_INFO changes Juergen Gross
2023-03-07 6:32 ` [PATCH 1/2] xen: move CONFIG_DEBUG_INFO out of EXPERT section Juergen Gross
2023-03-07 10:31 ` Jan Beulich
2023-03-07 11:33 ` Juergen Gross
2023-03-07 11:42 ` Jan Beulich
2023-03-07 12:04 ` Juergen Gross
2023-03-07 12:45 ` Jan Beulich
2023-03-07 6:32 ` [PATCH 2/2] xen: update CONFIG_DEBUG_INFO help text Juergen Gross
2023-03-07 10:41 ` Jan Beulich
2023-03-07 14:04 ` Juergen Gross
2023-03-07 14:18 ` Jan Beulich
2023-03-07 14:23 ` Juergen Gross
2023-03-07 14:34 ` Jan Beulich
2023-03-07 15:02 ` Juergen Gross
2023-03-07 15:14 ` Jan Beulich
2023-03-07 15:51 ` Juergen Gross
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).