public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Jordan Justen <jordan.l.justen@intel.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	"Shi, Steven" <steven.shi@intel.com>
Cc: "Kinney, Michael D" <michael.d.kinney@intel.com>,
	"edk2-devel-01" <edk2-devel@lists.01.org>,
	"afish@apple.com" <afish@apple.com>,
	"Gao, Liming" <liming.gao@intel.com>,
	mischief@offblast.org
Subject: Re: [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code
Date: Wed, 03 Aug 2016 13:13:58 -0700	[thread overview]
Message-ID: <147025523821.2704.13575318169553931780@jljusten-ivb> (raw)
In-Reply-To: <CAKv+Gu-xXSQ47Qo9F46H72zHo5_Bov4JvC5SnT11Q4iN+uriRQ@mail.gmail.com>

Where does this patch stand? I think Ard was asking for it to be
split, but also wondering if it was really required...

Some devs are still reporting unsupported relocation errors during the
build. (mischief on irc, for example.)

-Jordan

On 2016-08-02 05:00:43, Ard Biesheuvel wrote:
> On 2 August 2016 at 13:40, Shi, Steven <steven.shi@intel.com> wrote:
> >>
> >> CoffAddFixup() must be used for absolute symbol references only. These
> >> instructions contain relative symbol references, which are
> >> recalculated in WriteSections64().
> >>
> >> The only absolute symbol reference is the GOT entry for 'n', and your
> >> code (in WriteRelocations64()) calculates the address of the GOT entry
> >> (which is always in .text BTW) and adds a fixup for it, i.e.,
> >>
> >> +              CoffAddFixup(
> >> +                (UINT32)(UINTN)((UINT64)
> >> mCoffSectionsOffset[RelShdr->sh_info] + GoTPcRelPtrOffset),
> >> +                EFI_IMAGE_REL_BASED_DIR64);
> >>
> >> This code adds a fixup to the PE/COFF .reloc section for the GOT entry
> >> containing the address of 'n', and the instructions perform a IP
> >> relative load of the contents of the GOT entry to retrieve the address
> >> of 'n'.
> >>
> >> By adding two fixups, the PE/COFF loader will apply the load offset
> >> twice, resulting in an incorrect value.
> >>
> > OK, I get your point now. Yes, the current patch could generate multiple fixups for the same GOT relocation entry. How about we introduce a simple IsDuplicatedCoffFixup() to check whether a converting fixup offset is duplicated before we use CoffAddFixup() to really add it? If it is new, we add it, otherwise just skip it.
> 
> That could work, but you have to be aware that fixups are best emitted
> in the order they need to be applied in the binary, or it will become
> very inefficient. (Please refer to the PE/COFF spec section that
> explains the layout of the .reloc section)
> 
> What it comes down to is that relocations are grouped by target page,
> and for every place in the page that requires a relocation to be
> applied, a 4 bit type is emitted followed by a 12-bit offset, which is
> the offset into the current page. If you emit fixups for the current
> instruction, followed by one for the GOT, it will basically take two
> 'page switches' every time.
> 
> So it would be better to simply emit the relocations, but introduce a
> sorting pass that merges all duplicates as well.
> 
> Thanks,
> Ard.
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel


  reply	other threads:[~2016-08-03 20:14 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1467967364-11556-1-git-send-email-steven.shi@intel.com>
     [not found] ` <1467967364-11556-3-git-send-email-steven.shi@intel.com>
2016-07-30  9:25   ` [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code Ard Biesheuvel
2016-07-30 14:09     ` Shi, Steven
2016-07-30 14:11       ` Ard Biesheuvel
2016-07-31  3:08         ` Shi, Steven
2016-07-31  5:42           ` Ard Biesheuvel
2016-07-31 19:10             ` Ard Biesheuvel
2016-08-01  4:39               ` Shi, Steven
2016-08-01  5:58                 ` Ard Biesheuvel
2016-08-01  6:13                   ` Shi, Steven
2016-08-01  6:43                     ` Ard Biesheuvel
2016-08-01  7:19                       ` Shi, Steven
2016-08-01  7:25                         ` Ard Biesheuvel
2016-08-01  7:54                           ` Shi, Steven
2016-08-01  8:00                             ` Ard Biesheuvel
2016-08-01  8:28                               ` Shi, Steven
     [not found]                               ` <06C8AB66E78EE34A949939824ABE2B31033825EE@shsmsx102.ccr.corp.intel.com>
     [not found]                                 ` <CAKv+Gu80u+CJLVtD5tTo5RrJb7LH0Qfnbj=7b7NUqrbf2aOPrA@mail.gmail.com>
     [not found]                                   ` <06C8AB66E78EE34A949939824ABE2B31033826FE@shsmsx102.ccr.corp.intel.com>
     [not found]                                     ` <CAKv+Gu9MSisR1T_jr=DNyCs24We5=2vUgQZJ9t_rZmCYC8qvHg@mail.gmail.com>
     [not found]                                       ` <06C8AB66E78EE34A949939824ABE2B310338275F@shsmsx102.ccr.corp.intel.com>
2016-08-01 10:46                                         ` Ard Biesheuvel
2016-08-02 11:40                                           ` Shi, Steven
2016-08-02 12:00                                             ` Ard Biesheuvel
2016-08-03 20:13                                               ` Jordan Justen [this message]
2016-08-03 20:47                                                 ` Ard Biesheuvel
2016-08-03 20:53                                                   ` Jordan Justen
2016-08-03 20:55                                                     ` Ard Biesheuvel
2016-08-03 23:26                                                       ` Shi, Steven
2016-08-03 20:55                                                   ` Nicolas Owens

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-list 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=147025523821.2704.13575318169553931780@jljusten-ivb \
    --to=devel@edk2.groups.io \
    /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