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: Mon, 27 Jan 2014 22:13:00 -0000 [thread overview]
Message-ID: <CAMe9rOqOHTBo72s0b+++WfzfTHVWSO3MWOPN2M1QQ2+gTdCURQ@mail.gmail.com> (raw)
In-Reply-To: <CAMe9rOrUZB8ifn8oe07Q8aqcfZZesBWtoEid3ajfs2nzspMcdw@mail.gmail.com>
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.
--
H.J.
next prev parent reply other threads:[~2014-01-27 21:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-18 20:04 H.J. Lu
[not found] ` <CAMe9rOrUZB8ifn8oe07Q8aqcfZZesBWtoEid3ajfs2nzspMcdw@mail.gmail.com>
2014-01-27 22:13 ` H.J. Lu [this message]
2014-02-19 19:51 ` H.J. Lu
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=CAMe9rOqOHTBo72s0b+++WfzfTHVWSO3MWOPN2M1QQ2+gTdCURQ@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).