This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Add a new relocation to x86-64/i386 psABIs

On Mon, May 18, 2015 at 8:52 AM, Michael Matz <> 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

     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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]