xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "Roger Pau Monné" <roger.pau@citrix.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 15:06:36 +0200	[thread overview]
Message-ID: <6023c1d3-4f50-d207-1ea1-30dd1d5f68d2@suse.com> (raw)
In-Reply-To: <YIAJP0SCq0nOKZVL@Air-de-Roger>

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).

>> --- 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.

Jan


  reply	other threads:[~2021-04-21 13:06 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 [this message]
2021-04-21 15:30       ` Roger Pau Monné
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=6023c1d3-4f50-d207-1ea1-30dd1d5f68d2@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=roger.pau@citrix.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 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 NNTP newsgroup(s).