[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: Wed, 21 Apr 2021 17:30:23 +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=7seD1LasRbHT6lD7acTtdbEuctuqErrVk90P996TXho=; b=iN0MYZqa2/DM9lCfG9U3NCQ0H1XBMfm9caCOwVXJG9OZrSzFJuhyNlF+95T9EO3MhLyHdQtAOTdzvhdyBU3R2yhn0X+JsWvZAVtsKEcX4EKjgB/XG3qzV4aJm6OIUeVgRLIS5wjNIiOR225rssDCc7MkIcWVfwigVRTFq+6YOm6CsZLZh7SG+fBPRxEitYnt82awTG12BsEs3CJblO56fj4QjoVaH4tExYSHNtZ3GdBvuPdaoz3aMXVs2WDwtAJWGPXWFKKwiFqfJdkw7fhVllEvJKK8LSZEqSzgp/87VPW9pHZ0BjuNVCN88aVo575NbntmkI3caPiPGX2cP94b6g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cLY5Ic5z5roKtEpzKgu51grfAoa0omCWNu8brzBOeIIW/03VQJNmRda/QIvRUmtbwJNwQP8CdbNQAicRDJQi4BoyZXjBCoBmWo5lDajJ1ciLIGlA9ZPlXQ6BRntp1eDgSZfL1J6hr+YkTEmH+VTgDX5x0QaoxQexp24R1UMo6Xo+QPbmV8Ydq3Pkt2WVsDECDT0eMEjIe8nVDKyX/nckVP+wfgJy7KVyoijSArwKVcovvVwEhHo0HtJZAy01ky/xQuj8EWivGPtNCutblSw/j/ZojdCk7LE9SX7xShNn5LdTaDk83VdG6LTDu3qk5im2oo7d0I8nfcoVvb9bDrn5XQ==
  • Authentication-results: esa6.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: Wed, 21 Apr 2021 15:30:40 +0000
  • Ironport-hdrordr: A9a23:Tkun/6830l22zNtjU8Nuk+FJcL1zdoIgy1knxilNYDRvWIixi9 2ukPMH1RX9lTYWXzUalcqdPbSbKEmwybdc2qNUGbu5RgHptC+TLI9k5Zb/2DGIIUfD38Zn/+ Nbf6B6YeeaMXFTh8z3+RT9Nt4mzsWO/qzAv5an815GSwZ2Z6Z8qyJwDQiGGkN7LTM2fqYRPp ya+8ZBun6caW0aB/7LTUUtcsrig5nwlJzgaQMbHBJP0mWzpB6h9bKSKWn94j4wSDVKqI1CzU HklEjD6ryno7WHzHbnphbuxrB3vPek9ddZHsyLjaEuW3/RoyKlfp5oVbHHnB1dmpDJ1H8QnN PBowgtMq1Ighu/EF2dmhfj1xLt1zwj8RbZuDmlqEH+qs/0Ti9SMbsjuatlcwDU40dlnNZw3L Mj5RP9i7NrDAjNlCm42t7QVxsCrDvXnVMel4co70B3YM87Uvt8vIYf9ERaHNMrByTh8r0qF+ FoEYX1+OtWWUnyVQGUgkBfhPiXGlgjFBaPRUYP/uaP1SJNoXx/x0wEgOQCg3Y78o4nQZUs3Z WKDo1Y0JV1CuMGZ6N0A+kMBeGtDHbWfB7KOGWOZXPqCb8AIHCIj5Ls+r066KWLdfUzvdUPsa WEdGkdmX85ekroB8HL9oZM6ArxTGK0WimoxdpZ45R/p73gVLvmOSCOUzkV4oudisRaJveed+ e4OZpQDfOmB3DpA5x10wr3XIQXKXR2arxXhv8LH3a15u7bIIzjseLWNNzJIqD2LDoiUmTjRn 8KXD35ItRc/lmmM0WIwiT5ajfIQAjS7JhwGK/V86w4044WLLBBtQATlBC+/cGEKTpLt6QsZ0 tgKLb7kqe2zFPGvFrg3iFMAF5wH0xV6LLvXzdhvgkRKX75dr4FppGCY2xIxWCGIRV+VsvSFw Zaqz1MiOeKBq3V4RpnJ8OsM2qcgXdWmWmDSI0EnLafoe3/fIkjM5ogUKttNAnCGhBvgzx2oG NbZAJsfD6aKhrezYGeyL0dHqX2asR1igbDG78vlVvv8WGn4fwJalRedTi0SsKTiRspXFNv9y BM2p5apqGBlzapIXY4m8IiPjR3GSmqKbpbEQWIY5hVkLj3eAd2CXyHnyCelgtbQBuXy2wCwm PmNiGaYvfNHx5UvW1ZyL/j9BduenyaZF8YUAENjaRtUWDHsG10y+mFe+661HaQcEILxogmQU X4SCpXJgNl3Nas0hGJ3D6ECHU9350reujQFq4qfb2W2nSjLuSz5NY7Nu4R+JZuL9b1tOAXFe qZZg+ONTv9T/ozxBb9nAdXBABk7H0/1f/40hzs62a1mHY5HPrJOVxjA7UWOcuV4WToT+uBua 8JxO4drK+1KCH8e9SGwabYY3pYJhTfrXW/QusopZpX1JhCwYdbDt3eS3/FxXtH1BIxIIPoj0 sYWr18+62ENYl1fcAeEhgptmYBhZCKNg8svQP3CONlIg1ogH/fIt+T473H7bAoGVaMoQPsOV +Zty1Rls21LherxPofEeY3J28TdU03rHJl9+mGf5fLCAqre/pYlWDKQEOVYftYUuydBb4Urh xm+NmGkO+cajrg1GnrzEVGC7ML93ziXNi7Dw2NE/NZ6tC2OVyDha2x/c645Q2HOQeTegAfno 1KdUsZc8RFhH0jleQMo1ePdpA=
  • Ironport-sdr: nrGl7Tc2OPjYsOc9A0cWjD8yx6V2rSgnr670QhqnWCtnx4ECoxrQyQHU0PXd/JGChJ6jOR/zta /TBL18RtHZPEku89ZCEdtaeOaxyPno8SfOCaUIi4+FmwdjTAS8+rS550VwAs9exf2qBb+J/bgV OtZLV4gQFpakwcCUY5mfGhfgGJ8yZDDKtB3Zl0EW3pyhyFzs3zGN3mZMQt/TAui+zDIrb11OJx 38cK3fnJ0+1p5MqG/llRzKq41V4gf2mhq3uBCy18w3uuMFPQNfKCK+3aj/TUMXQKUCZ1pKZcdC 9Z0=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.



 


Rackspace

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