From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>
Subject: Re: [PATCH 7/8] x86/EFI: keep debug info in xen.efi
Date: Wed, 21 Apr 2021 17:30:23 +0200 [thread overview]
Message-ID: <YIBFD4i6bLaeaXdE@Air-de-Roger> (raw)
In-Reply-To: <6023c1d3-4f50-d207-1ea1-30dd1d5f68d2@suse.com>
On Wed, Apr 21, 2021 at 03:06:36PM +0200, Jan Beulich wrote:
> On 21.04.2021 13:15, Roger Pau Monné wrote:
> > On Thu, Apr 01, 2021 at 11:47:03AM +0200, Jan Beulich wrote:
> >> ... provided the linker supports it (which it does as of commit
> >> 2dfa8341e079 ["ELF DWARF in PE output"]).
> >>
> >> Without mentioning debugging sections, the linker would put them at
> >> VA 0, thus making them unreachable by 32-bit (relative or absolute)
> >> relocations. If relocations were resolvable (or absent) the resulting
> >> binary would have invalid section RVAs (0 - __image_base__, truncated to
> >> 32 bits). Mentioning debugging sections without specifying an address
> >> will result in the linker putting them all on the same RVA. A loader is,
> >> afaict, free to reject loading such an image, as sections shouldn't
> >> overlap. (The above describes GNU ld 2.36 behavior, which - if deemed
> >> buggy - could change.)
> >
> > Isn't just using (NOLOAD) to signal those sections shouldn't be
> > loaded enough, and thus don't care about it's RVA?
>
> As said in a reply earlier on another sub-thread, (NOLOAD) is meaningless
> for PE. The fact that I add them nevertheless is just for docs purposes
> (or if, in the future, the item gains significance).
>
> The main problem though isn't "load" vs "no-load" but, as I thought I
> have expressed in the description, that there's no "don't care about it's
> RVA" in PE. All sections have to have a non-zero VA above the image base.
> This is the only way via which sane RVA values can result. If sections
> get placed at VA 0 (which is perfectly fine for ELF), the RVA would be a
> huge negative number truncated to 32 bits. (Again, prior to binutils 2.37
> this will go all silently.) Plus the respective sections would come first
> (rather than last) in the binary (which by itself may or may not be a
> problem for the EFI loader, but I wouldn't want to chance it).
Thanks for the explanation.
> >> --- a/xen/arch/x86/xen.lds.S
> >> +++ b/xen/arch/x86/xen.lds.S
> >> @@ -312,10 +312,60 @@ SECTIONS
> >> *(.reloc)
> >> __base_relocs_end = .;
> >> }
> >> - /* Trick the linker into setting the image size to exactly 16Mb. */
> >> - . = ALIGN(__section_alignment__);
> >> - DECL_SECTION(.pad) {
> >> - . = ALIGN(MB(16));
> >> + .debug_abbrev ALIGN(1) (NOLOAD) : {
> >> + *(.debug_abbrev)
> >> + }
> >> + .debug_info ALIGN(1) (NOLOAD) : {
> >> + *(.debug_info)
> >> + *(.gnu.linkonce.wi.*)
> >> + }
> >> + .debug_types ALIGN(1) (NOLOAD) : {
> >> + *(.debug_types)
> >> + }
> >> + .debug_str ALIGN(1) (NOLOAD) : {
> >> + *(.debug_str)
> >> + }
> >> + .debug_line ALIGN(1) (NOLOAD) : {
> >> + *(.debug_line)
> >> + *(.debug_line.*)
> >> + }
> >> + .debug_line_str ALIGN(1) (NOLOAD) : {
> >> + *(.debug_line_str)
> >> + }
> >> + .debug_names ALIGN(4) (NOLOAD) : {
> >> + *(.debug_names)
> >> + }
> >> + .debug_frame ALIGN(4) (NOLOAD) : {
> >> + *(.debug_frame)
> >> + }
> >> + .debug_loc ALIGN(1) (NOLOAD) : {
> >> + *(.debug_loc)
> >> + }
> >> + .debug_loclists ALIGN(4) (NOLOAD) : {
> >> + *(.debug_loclists)
> >> + }
> >> + .debug_ranges ALIGN(8) (NOLOAD) : {
> >> + *(.debug_ranges)
> >> + }
> >> + .debug_rnglists ALIGN(4) (NOLOAD) : {
> >> + *(.debug_rnglists)
> >> + }
> >> + .debug_addr ALIGN(8) (NOLOAD) : {
> >> + *(.debug_addr)
> >> + }
> >> + .debug_aranges ALIGN(1) (NOLOAD) : {
> >> + *(.debug_aranges)
> >> + }
> >> + .debug_pubnames ALIGN(1) (NOLOAD) : {
> >> + *(.debug_pubnames)
> >> + }
> >> + .debug_pubtypes ALIGN(1) (NOLOAD) : {
> >> + *(.debug_pubtypes)
> >> + }
> >> + /* Trick the linker into setting the image size to no less than 16Mb. */
> >> + __image_end__ = .;
> >> + .pad ALIGN(__section_alignment__) : {
> >> + . = __image_end__ < __image_base__ + MB(16) ? ALIGN(MB(16)) : .;
> >
> > I think this is inside an ifdef EFI region, since this is DWARF info
> > couldn't it also be present when building with EFI disabled?
>
> Of course (and it's not just "could" but "will"), yet the linker will
> do fine (and perhaps even better) without when building ELF. Also
> note that we'll be responsible for keeping the list of sections up-to-
> date. The linker will recognize Dwarf sections by looking for a
> .debug_ prefix. We can't use such here (or at least I'm not aware of
> a suitable mechanism); .debug_* would mean munging together all the
> different kinds of Dwarf sections. Hence by limiting the explicit
> enumeration to PE, I'm trying to avoid anomalies in ELF down the road.
Right, so we will have to keep this list of debug_ sections updated
manually if/when more of those appear as part of DWARF updates?
Do we have a way to get some kind of warning or error when a new
section not explicitly handled here appears?
Instead of adding DWARF debug info to the xen.efi binary, is there a
way to translate the DWARF from the ELF build into the native debug
format for PE/COFF?
Thanks, Roger.
next prev parent reply other threads:[~2021-04-21 15:30 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-01 9:43 [PATCH 0/8] x86/EFI: build adjustments Jan Beulich
2021-04-01 9:44 ` [PATCH 1/8] x86/EFI: drop stale section special casing when generating base relocs Jan Beulich
2021-04-01 11:51 ` Andrew Cooper
2021-04-01 9:44 ` [PATCH 2/8] x86/EFI: sections may not live at VA 0 in PE binaries Jan Beulich
2021-04-01 12:01 ` Andrew Cooper
2021-04-01 13:51 ` Jan Beulich
2021-04-21 8:52 ` Roger Pau Monné
2021-04-21 10:32 ` Jan Beulich
2021-04-21 12:57 ` Roger Pau Monné
2021-04-21 13:28 ` Jan Beulich
2021-04-01 9:45 ` [PATCH 3/8] x86/EFI: program headers are an ELF concept Jan Beulich
2021-04-21 9:11 ` Roger Pau Monné
2021-04-21 10:36 ` Jan Beulich
2021-04-21 14:21 ` Roger Pau Monné
2021-04-21 14:30 ` Jan Beulich
2021-04-01 9:45 ` [PATCH 4/8] x86/EFI: redo .reloc section bounds determination Jan Beulich
2021-04-21 9:46 ` Roger Pau Monné
2021-04-21 10:44 ` Jan Beulich
2021-04-21 14:54 ` Roger Pau Monné
2021-04-01 9:46 ` [PATCH 5/8] x86: drop use of prelink-efi.o Jan Beulich
2021-04-21 9:51 ` Roger Pau Monné
2021-04-01 9:46 ` [PATCH 6/8] x86/EFI: avoid use of GNU ld's --disable-reloc-section when possible Jan Beulich
2021-04-21 10:21 ` Roger Pau Monné
2021-04-21 12:03 ` Jan Beulich
2021-04-21 15:20 ` Roger Pau Monné
2021-04-21 15:34 ` Jan Beulich
2021-04-22 7:22 ` Roger Pau Monné
2021-04-22 10:42 ` Jan Beulich
2021-04-01 9:47 ` [PATCH 7/8] x86/EFI: keep debug info in xen.efi Jan Beulich
2021-04-21 11:15 ` Roger Pau Monné
2021-04-21 13:06 ` Jan Beulich
2021-04-21 15:30 ` Roger Pau Monné [this message]
2021-04-21 15:38 ` Jan Beulich
2021-04-22 8:14 ` Roger Pau Monné
2021-04-22 11:03 ` Jan Beulich
2021-04-22 14:56 ` Roger Pau Monné
2021-04-22 15:46 ` Jan Beulich
2021-04-22 15:53 ` Roger Pau Monné
2021-04-22 16:01 ` Jan Beulich
2021-04-23 7:30 ` Roger Pau Monné
2021-04-23 8:51 ` Jan Beulich
2021-04-23 10:07 ` Roger Pau Monné
2021-04-23 10:45 ` Jan Beulich
2021-04-23 10:58 ` Roger Pau Monné
2021-04-01 9:47 ` [PATCH 8/8] x86/EFI: don't have an overly large image size Jan Beulich
2021-04-21 11:18 ` Roger Pau Monné
2021-04-21 13:15 ` Jan Beulich
2021-04-15 9:53 ` Ping: [PATCH 0/8] x86/EFI: build adjustments Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YIBFD4i6bLaeaXdE@Air-de-Roger \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.