[PATCH] gas: Fix some x86_64 testcases for Solaris not using R_X86_64_PLT32 [PR25732]

[Fangrui Song]

On 2020-04-02, Rainer Orth wrote:
>Hi Fangrui,
>
>> On 2020-04-01, H.J. Lu via Binutils wrote:
>>>On Wed, Apr 1, 2020 at 3:47 AM Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
>>>>
>>>> As reported in PR gas/25732, some testcases currently FAIL on
>>>> Solaris/x86:
>>>>
>>>> FAIL: x86-64 branch 2
>>>> FAIL: x86-64 branch 3
>>>> FAIL: x86-64 MPX branch
>>>> FAIL: x86-64 branch with BND prefix
>>>> FAIL: x86-64 jump
>>>>
>>>> Since https://sourceware.org/ml/binutils/2019-03/msg00163.html, gas
>>>> doesn't emit R_X86_64_PLT32 as branch marker on Solaris.  Since the
>>>> testsuite lacks a way to preprocess dump files, adjusted copies of the
>>>> affected dumps are now used on Solaris.  Unfortunately, those dumps
>>>> weren't adapted when the original testcases were changed or other
>>>> testcases started to differ between non-Solaris and Solaris targets.
>>>>
>>>> The following patch fixes that, re-syncing the affected dump files or
>>>> creating new Solaris-specific ones.
>>>>
>>>> Tested on i386-pc-solaris2.11, x86_64-pc-solaris2.11,
>>>> x86_64-pc-linux-gnu, and i686-pc-linux-gnu.
>>>>
>>>> Ok for master?
>>>>
>>>
>>>OK.
>>>
>>>BTW, please watch out for future adjustments similar to this.
>>>
>>>Thanks.
>>
>> Why doesn't Solaris x86 use R_X86_64_PLT32?
>
>it does, it just doesn't want to implement support for HJ's branch
>marker optimization referred to in the patch linked above.  Some of that
>is explained in my patch submission, buf if you want to know all the
>gory details, ask Ali ;-)

Looking at the tests, if I guess correctly, a @plt modifier is required
to emit R_X86_64_PLT32. I have put many thoughts in this area.  HJ's
branch marker optimization is a great thing to me.

R_X86_64_PLT32 is categorized as R_PLT_PC (a PC-relative relocation
which may create a PLT entry). It can be relaxed to R_PC (a PC-relative
relocation) if the symbol is non-preemptible (logical AND (non-ifunc or
FreeBSD extension -z ifunc-noplt); I know Solaris will never support ifunc).

A PLT32 has less requirement than a PC32. A PLT32 means the address is
not significant. The linker can use whatever approach appropriate to
arrange for a call to the symbol. It can be a direct jump, a jump
through a PLT entry, or other novel approach if it prefers.

A PC32, on the other hand, is indistinguishable with an address taken
operation.  This causes us copy relocations and canonical PLT entries (I
should note that I've seen a few people (at least Rafael Espindola and
Cary Coutant) using the term "canonical PLT entry" but it is not widely
used).

When emitting a jump/call instruction, it is unnecessary for the
compiler to emit extra info: R_X86_64_PLT32 vs R_X86_64_PC32;
R_PPC_LOCAL24PC vs R_PPC_PLTREL24 vs R_PPC_REL24. It is great that PPC64
dropped some relocation types in contrast to PPC32...

The non-preemptible property is a mergeable property of the symbol, not
an unmergeable property of the relocation.

I made a complaint about RISC-V's call relocation types while working on
the RISC-V port for lld
https://github.com/riscv/riscv-elf-psabi-doc/issues/98 R_RISCV_CALL vs R_RISCV_CALL_PLT

 From the viewpoint of implementation, with proper abstraction,
R_X86_64_PLT32 -> R_X86_64_PC32 can be implemented with very little
code:

https://github.com/llvm/llvm-project/blob/master/lld/ELF/Relocations.cpp#L1329
plus the definition of fromPlt

   if (!sym.isPreemptible && (!sym.isGnuIFunc() || config->zIfuncNoplt)) {
     if (expr == R_GOT_PC && !isAbsoluteValue(sym)) {
       /// For the curious, this is the recent https://sourceware.org/bugzilla/show_bug.cgi?id=25754
       expr = target->adjustRelaxExpr(type, relocatedAddr, expr);
     } else {
       // The 0x8000 bit of r_addend of R_PPC_PLTREL24 is used to choose call
       // stub type. It should be ignored if optimized to R_PC.
       if (config->emachine == EM_PPC && expr == R_PPC32_PLTREL)
         addend &= ~0x8000;
       expr = fromPlt(expr);
     }
   }


>> Disclosure: I know close to zero about Solaris.
>
>That can be changed :-)  For one, there's the Linkers and Libraries Guide
>
>	https://docs.oracle.com/cd/E37838_01/html/E36783/index.html
>
>written by the linker engineers themselves.  And for even more
>background, you can check out their blog
>
>	http://www.linker-aliens.org/
>
>Both make for quite interesting reading for anyone interested in ELF in
>general and Solaris innovations in particular.
>
>	Rainer
>-- 
>-----------------------------------------------------------------------------
>Rainer Orth, Center for Biotechnology, Bielefeld University

I take this as a very friendly invitation to ask me to read:) Thanks.
I have read some when I started to work on lld. They are phrased very
well and have taught me a lot. As a linker and loader lover, I should
finish reading the Linkers and Libraries Guide...
It is refreshing to get some non-GNU perspective.