[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 7/8] x86/EFI: keep debug info in xen.efi


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Thu, 22 Apr 2021 16:56:44 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tkRbo7Btuf6OptzIMrsyMrsHpwkQPM24A5LsXU73zhg=; b=kEh2YJ2+Dy54Oh5Jnd4oBNA/f8e0LnUgVpO3h4ZIRglhGEpZ9CQ9huOW2qgk1XXUejxAyf1v1M2cC6YPk4k/GYbGPhWL5RkltBTKJApsvcMK46esLDOC5djxCdpUKxadAoA7rAk0HRtNyJRz901OaEfpNYoV5ClpDPhgTZqoEqUd0VIwk60fu1up7BkDvFGFkWea6XtYXEhzfwekT+6xnICWdqAhYeqF7Z6lY7XRwi3J2zBaauajpPdUY5gZ1ZVofVe4uwyU73XvLj6XNYGJeGI2eHc/rswpZZZybG+qlwRtn+l3WUdfKodfZDT1mRfl9AgIX7OtlYH7hTgahIK2uA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YNr9u6RcDFrMhg7DMAxmZTrYD8j1eEBD10zQScLxzoyjljAZsjb+MPWh45652gD1JDqC5Zc3a95eed0Iz3ZGJMroGZ/8Eu0Z2my6fiMyDUHlK6zX2fcJ6zS5n9eVaNAGG6+cjKLY2+DLgrjg1OmdGXV9zZieYCBdu9ktlG9lFX6N9oZChsUGHRb5OncHNyC85d2E/TpFpcuAS480hTxuLLpP886XwHgEgrAdzL8bUNaNE31kh4Ya43oqFtlhFP80fbl52dAY+1LG8Fu1H1fv0qlD12fBYT1ncNM9Aa6PKI1Fmm31DHIDaMDbJpHElfrnqRF1W89iyvbK/mDwtl1k6g==
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "Andrew Cooper" <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Thu, 22 Apr 2021 14:57:02 +0000
  • Ironport-hdrordr: A9a23:E4jUya/RaNm1NTT9jqNuk+EKdb1zdoIgy1knxilNYDRIb82VkN 2vlvwH1RnyzA0cQm0khMroAsS9aFnXnKQU3aA6O7C+UA76/Fa5NY0K1/qH/xTMOQ3bstRc26 BpbrRkBLTLZ2RSoM7m7GCDfOoI78KA9MmT69v261dIYUVUZ7p77wF/Yzzrd3FeYAVdH5I2GN 69y6N81lmdUE8aZMi6GXUJNtKrz7H2vanrfAIcAFof4BSO5AnC1JfBDxOa0h0COgk/o4sKzG 6tqW3Ez5Tmid6X4Fv212jf75NZ8eGRt+drNYi3peU+bhnpggasTox9V7OFpyBdmpDS1H8a1O Pijj1lE8Nv627AXmzdm2qT5yDQlAwAxlWn6ViEjWDtqcb0LQhKdfZptMZiXTbyr28D1esMt5 5j7iaimLd8SS7kpmDb4ePFUhl7/3DE2kYKoKoooFF0FbcFZKQ5l/14wGplVK0uMQjd844dHO xnHKjnlYxrWGLfVXzfs2V1qebcJ0gbL1ODSkgGjMSfzyJbqnB/11cZ38wShB47heoAd6U=
  • Ironport-sdr: 34x5A2WcSaFLPQHoUtPeg9nY7M0CYC+Hpqq4qx0IrnSA2hGOIKx0wIZybVIiEYOwY5bPUxClL3 WqZwO3NvDEvq/z6BNww9RpBuAzNUmKOGitAosjHzgImWtYyG/OCXeV5rSmZL3khpP0nmex7ZNj jj8ELO2BqoPkPVRSxRCwV3Fv3qxH+DXzYTwQx3hhbAPYKfV33wL21ZuA44u4aRqgUjRlCdALy2 /dagAvx6t3PwESXRRumwylzMBKXcDLV0tXlcV6dStKHSXuwPAx5bXSnjCf8xEFcSj7mT/dkb5j OoU=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Apr 22, 2021 at 01:03:13PM +0200, Jan Beulich wrote:
> On 22.04.2021 10:14, Roger Pau Monné wrote:
> > On Wed, Apr 21, 2021 at 05:38:42PM +0200, Jan Beulich wrote:
> >> On 21.04.2021 17:30, Roger Pau Monné wrote:
> >>> 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:
> >>>>>> --- 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?
> >>
> >> Yes.
> >>
> >>> Do we have a way to get some kind of warning or error when a new
> >>> section not explicitly handled here appears?
> >>
> >> ld 2.37 will start warning about such sections, as they'd land at
> >> VA 0 and hence below image base.
> > 
> > That seems like a bug in ld?
> > 
> > The '--image-base' option description mentions: "This is the lowest
> > memory location that will be used when your program or dll is
> > loaded.", so I would expect that if the option is used the default VA
> > should be >= image-base, or else the description of the option is not
> > consistent, as ld will still place sections at addresses below
> > image-base.
> 
> ld's "general" logic is pretty ELF-centric. Hence debugging sections
> get placed at VA 0 by default, not matter what the (PE-specific)
> --image-base says. Whether that's a bug though I'm not sure: There
> are no really good alternatives that could be used by default. Doing
> what we do here (and what e.g. Cygwin does) via linker script may not
> be appropriate in the common case. In particular it is not generally
> correct for debug info to be part of what gets loaded into memory.

So with this change here you placate the warnings from newer ld about
having a VA < image base, but the end result is that now the debug
sections will also get loaded when booted from the EFI loader?
(because the NOLOAD doesn't have any effect with PE)

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.