public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: GCC Development <gcc@gcc.gnu.org>,
	GNU C Library <libc-alpha@sourceware.org>,
		Binutils <binutils@sourceware.org>, GDB <gdb@sourceware.org>,
		"x86-64-abi@googlegroups.com" <x86-64-abi@googlegroups.com>
Cc: Igor Zamyatin <izamyatin@gmail.com>
Subject: Re: Update x86-64 PLT for MPX
Date: Wed, 19 Feb 2014 19:51:00 -0000	[thread overview]
Message-ID: <CAMe9rOpT-VFHParPJEEjbvKDc4BMD+syU4mbOz4bLj_nG+NU_g@mail.gmail.com> (raw)
In-Reply-To: <CAMe9rOqOHTBo72s0b+++WfzfTHVWSO3MWOPN2M1QQ2+gTdCURQ@mail.gmail.com>

On Mon, Jan 27, 2014 at 1:50 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Jan 27, 2014 at 1:42 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Sat, Jan 18, 2014 at 8:11 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> Hi,
>>>
>>> Here is the proposal to update x86-64 PLT for MPX.  The linker change
>>> is implemented on hjl/mpx/pltext8 branch.  Any comments/feedbacks?
>>>
>>> Thanks.
>>>
>>> --
>>> H.J.
>>> ---
>>> Intel MPX:
>>>
>>> http://software.intel.com/en-us/file/319433-017pdf
>>>
>>> introduces 4 bound registers, which will be used for parameter passing
>>> in x86-64.  Bound registers are cleared by branch instructions.  Branch
>>> instructions with BND prefix will keep bound register contents. This leads
>>> to 2 requirements to 64-bit MPX run-time:
>>>
>>> 1. Dynamic linker (ld.so) should save and restore bound registers during
>>> symbol lookup.
>>> 2. Change the current 16-byte PLT0:
>>>
>>>   ff 35 08 00 00 00    pushq  GOT+8(%rip)
>>>   ff 25 00 10 00    jmpq  *GOT+16(%rip)
>>>   0f 1f 40 00        nopl   0x0(%rax)
>>>
>>> and 16-byte PLT1:
>>>
>>>   ff 25 00 00 00 00        jmpq   *name@GOTPCREL(%rip)
>>>   68 00 00 00 00           pushq  $index
>>>   e9 00 00 00 00           jmpq   PLT0
>>>
>>> which clear bound registers, to preserve bound registers.
>>>
>>> We use 2 new relocations:
>>>
>>> #define R_X86_64_PC32_BND  39 /* PC relative 32 bit signed with BND prefix */
>>> #define R_X86_64_PLT32_BND 40 /* 32 bit PLT address with BND prefix */
>>>
>>> to mark branch instructions with BND prefix.
>>>
>>> When linker sees any R_X86_64_PC32_BND or R_X86_64_PLT32_BND relocations,
>>> it switches to a different PLT0:
>>>
>>>   ff 35 08 00 00 00    pushq  GOT+8(%rip)
>>>   f2 ff 25 00 10 00    bnd jmpq *GOT+16(%rip)
>>>   0f 1f 00        nopl   (%rax)
>>>
>>> to preserve bound registers for symbol lookup and it also creates an
>>> external PLT section, .pl.bnd.  Linker will create a BND PLT1 entry
>>> in .plt:
>>>
>>>   68 00 00 00 00           pushq  $index
>>>   f2 e9 00 00 00 00     bnd jmpq PLT0
>>>   0f 1f 44 00 00        nopl 0(%rax,%rax,1)
>>>
>>> and a 8-byte BND PLT entry in .plt.bnd:
>>>
>>>   f2 ff 25 00 00 00 00  bnd jmpq *name@GOTPCREL(%rip)
>>>   90            nop
>>>
>>> Otherwise, linker will create a legacy PLT entry in .plt:
>>>
>>>   68 00 00 00 00           pushq  $index
>>>   e9 00 00 00 00        jmpq PLT0
>>>   66 0f 1f 44 00 00     nopw 0(%rax,%rax,1)
>>>
>>> and a 8-byte legacy PLT in .plt.bnd:
>>>
>>>   ff 25 00 00 00 00     jmpq  *name@GOTPCREL(%rip)
>>>   66 90                 xchg  %ax,%ax
>>>
>>> The initial value of the GOT entry for "name" will be set to the the
>>> "pushq" instruction in the corresponding entry in .plt.  Linker will
>>> resolve reference of symbol "name" to the entry in the second PLT,
>>> .plt.bnd.
>>>
>>> Prelink stores the offset of pushq of PLT1 (plt_base + 0x10) in GOT[1]
>>> and GOT[1] is stored in GOT[3].  We can undo prelink in GOT by computing
>>> the corresponding the pushq offset with
>>>
>>> GOT[1] + (GOT offset - &GOT[3]) * 2
>>>
>>> Since for each entry in .plt except for PLT0 we create a 8-byte entry in
>>> .plt.bnd, there is extra 8-byte per PLT symbol.
>>>
>>> We also investigated the 16-byte entry for .plt.bnd.  We compared the
>>> 8-byte entry vs the the 16-byte entry for .plt.bnd on Sandy Bridge.
>>> There are no performance differences in SPEC CPU 2000/2006 as well as
>>> micro benchmarks.
>>>
>>> Pros:
>>>     No change to undo prelink in dynamic linker.
>>>     Only 8-byte memory overhead for each PLT symbol.
>>> Cons:
>>>     Extra .plt.bnd section is needed.
>>>     Extra 8 byte for legacy branches to PLT.
>>>     GDB is unware of the new layout of .plt and .plt.bnd.
>>
>> Hi,
>>
>> I am enclosing the updated x86-64 psABI with PLT change.
>> I checkeMy email is rejected due to PDF attachment.   I am resubmitting it with
> out PDF file.
> d it onto hjl/mpx/master branch at
>>
>> https://github.com/hjl-tools/x86-64-psABI
>>
>> I will check in the binutils changes if there are no disagreements
>> in 2 weeks.
>>
>> Thanks.
>
>
> My email is rejected due to PDF attachment.   I am resubmitting it with
> out PDF file.

I pushed the MPX binutils change into master:

https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=0ff2b86e7c14177ec7f9e1257f8e697814794017


-- 
H.J.

      reply	other threads:[~2014-02-19 19:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-18 16:11 H.J. Lu
     [not found] ` <CAMe9rOrUZB8ifn8oe07Q8aqcfZZesBWtoEid3ajfs2nzspMcdw@mail.gmail.com>
2014-01-27 21:50   ` H.J. Lu
2014-02-19 19:51     ` H.J. Lu [this message]

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=CAMe9rOpT-VFHParPJEEjbvKDc4BMD+syU4mbOz4bLj_nG+NU_g@mail.gmail.com \
    --to=hjl.tools@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=gcc@gcc.gnu.org \
    --cc=gdb@sourceware.org \
    --cc=izamyatin@gmail.com \
    --cc=libc-alpha@sourceware.org \
    --cc=x86-64-abi@googlegroups.com \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).