xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
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 13:15:11 +0200	[thread overview]
Message-ID: <YIAJP0SCq0nOKZVL@Air-de-Roger> (raw)
In-Reply-To: <96cb4039-5f43-8eac-d855-c9f1587ed2d0@suse.com>

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?

> 
> Make sure our up-to-16Mb padding doesn't unnecessarily further extend
> the image.
> 
> Take the opportunity and also switch to using $(call ld-option,...).
> 
> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> This way we could also avoid discarding .comment for xen.efi.
> 
> I'd like to point out that the linking of the debug info takes far
> longer than the linking of the "normal" parts of the image. The change
> therefore has the downside of slowing down debug builds.
> 
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -126,8 +126,14 @@ export XEN_BUILD_EFI := $(shell $(CC) $(
>  CFLAGS-$(XEN_BUILD_EFI) += -DXEN_BUILD_EFI
>  
>  # Check if the linker supports PE.
> -EFI_LDFLAGS = $(patsubst -m%,-mi386pep,$(XEN_LDFLAGS)) --subsystem=10 --strip-debug
> -XEN_BUILD_PE := $(if $(XEN_BUILD_EFI),$(shell $(LD) $(EFI_LDFLAGS) -o efi/check.efi efi/check.o 2>/dev/null && echo y))
> +EFI_LDFLAGS = $(patsubst -m%,-mi386pep,$(XEN_LDFLAGS)) --subsystem=10
> +XEN_BUILD_PE := $(if $(XEN_BUILD_EFI),$(call ld-option,$(EFI_LDFLAGS) --image-base=0x100000000 -o efi/check.efi efi/check.o))
> +# If the above failed, it may be merely because of the linker not dealing well
> +# with debug info. Try again with stripping it.
> +ifeq ($(CONFIG_DEBUG_INFO)-$(XEN_BUILD_PE),y-n)
> +EFI_LDFLAGS += --strip-debug
> +XEN_BUILD_PE := $(call ld-option,$(EFI_LDFLAGS) --image-base=0x100000000 -o efi/check.efi efi/check.o)
> +endif
>  
>  ifeq ($(XEN_BUILD_PE),y)
>  
> @@ -232,6 +238,9 @@ note_file_option ?= $(note_file)
>  
>  ifeq ($(XEN_BUILD_PE),y)
>  $(TARGET).efi: prelink.o $(note_file) efi.lds efi/relocs-dummy.o efi/mkreloc
> +ifeq ($(CONFIG_DEBUG_INFO),y)
> +	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),echo,:) "Will strip debug info from $(@F)"
> +endif
>  	$(foreach base, $(VIRT_BASE) $(ALT_BASE), \
>  	          $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< $(relocs-dummy) \
>  	                $(BASEDIR)/common/symbols-dummy.o $(note_file_option) -o $(@D)/.$(@F).$(base).0 &&) :
> --- 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?

Maybe I'm missing part of the point here, sorry.

Thanks, Roger.


  reply	other threads:[~2021-04-21 11:15 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é [this message]
2021-04-21 13:06     ` Jan Beulich
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=YIAJP0SCq0nOKZVL@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 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).