This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: RFC: Add a new relocation to x86-64/i386 psABIs
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: IA32 System V Application Binary Interface <ia32-abi at googlegroups dot com>, "x86-64-abi at googlegroups dot com" <x86-64-abi at googlegroups dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Binutils <binutils at sourceware dot org>
- Date: Mon, 18 May 2015 09:12:15 -0700
- Subject: Re: RFC: Add a new relocation to x86-64/i386 psABIs
- Authentication-results: sourceware.org; auth=none
- References: <20150518124042 dot GA16768 at gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1505181509310 dot 27315 at wotan dot suse dot de> <CAMe9rOow4vz-bkWH5GKAPgJu_jbRZQF6y4Nnh=M+2R4BjgwV8g at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1505181746200 dot 27315 at wotan dot suse dot de>
On Mon, May 18, 2015 at 8:52 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Mon, 18 May 2015, H.J. Lu wrote:
>
>> Yes, we should convert it to
>>
>> nop call foo/jmp foo nop
>>
>> I implemented it on users/hjl/relax branch in binutils git repo.
>>
>> > the insn decoder. For calls as well of course, but there it might be
>> > better to have it before the call.
>> >
>>
>> I think a nop prefix is better on call. We won't mandate "nop call foo"
>> in psABI and linker is free to use either a nop prefix or a nop suffix.
>>
>> Should we move forward with it?
>
> I think I have only nit-picking left: why call the whole thing relax? To
> me relax implies some length-changing transformation (like jump target
> relaxing, emitting shorter jumps when in range), but perhaps that's just
> me. OTOH I can't think of a better name right now.
Me neither. Linker manual has
'--relax'
'--no-relax'
An option with machine dependent effects. This option is only
supported on a few targets. *Note 'ld' and the H8/300: H8/300.
*Note 'ld' and the Intel 960 family: i960. *Note 'ld' and Xtensa
Processors: Xtensa. *Note 'ld' and the 68HC11 and 68HC12:
M68HC11/68HC12. *Note 'ld' and the Altera Nios II: Nios II. *Note
'ld' and PowerPC 32-bit ELF Support: PowerPC ELF32.
On some platforms the '--relax' option performs target specific,
global optimizations that become possible when the linker resolves
addressing in the program, such as relaxing address modes,
synthesizing new instructions, selecting shorter version of current
instructions, and combining constant values.
On some platforms these link time global optimizations may make
symbolic debugging of the resulting executable impossible. This is
known to be the case for the Matsushita MN10200 and MN10300 family
of processors.
In this sense, calling this scheme "relax" is not entirely inaccurate.
> Then one remark: there's a small interaction between this scheme and
> taking the address of a function. I _think_ it's all taken care of, but
I believe so.
> just want to make sure it is: the relax scheme must only apply to the
> .got.plt slot, not to the normal .got slot (which must continue to hold
> the final function address), and with the recent sharing you have
> implemented (when both are needed) it must be ensured that also an
> existing RELAX_GOTPCREL reloc doesn't overwrite that .got slot with the
> .plt entry address.
Since .got and .got.plt slots serve the same purpose, ld already
combines them into one single .got slot with .plt entry pointing to
the .got slot. That is if you take the address of the function and
branch to it, linker will arrange .plt entry to do an indirect branch
via its got slot.
--
H.J.