[Bug gas/20427] Solaris rtld on SPARC does not allow R_SPARC_UA64 or R_SPARC_64 relocations in 32-bit executables

[stefan.teleman at oracle dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20427

--- Comment #4 from Stefan Teleman <stefan.teleman at oracle dot com> ---
Hi Nick,

(In reply to Nick Clifton from comment #3)
> Hi Stefan,
> 
> > proposed patch -- tc-sparc.c.patch
> 
> I have a couple of questions about this patch:
> 
>   1.  There appear to be other places in cons_fix_new_sparc() where
>       64-bit relocs can be generated (ie BFD_RELOC_64_PCREL, 
>       BFD_RELOC_SPARC_PLT64 and BFD_RELOC_SPARC_TLS_DTPOFF64) but the
>       patch does not affect them.  Why not ?

Mainly because i haven't been able to come up with a test case which
would trigger gas to emit these 64-bit relocations in 32-bit. I can try
coming up with test cases for these as well. This would actually be quite
useful.

> 
>   2. The relocs that you are changing are intended to install 64-bit 
>      values into the binary.  By changing them to 32-bit versions it
>      seems like you are loosing the upper bits.  Have you run any tests
>      to see if 64-bit values are still handled correctly after applying
>      the patch ?  [It would be useful to know what the Solaris assembler
>      does in these circumstances.  Does it, for example, produce two
>      32-bit relocs, one for the lower 32-bits and one for the upper 
>      32-bits ?]

I have verified that the values are being handled correctly with the gas +
Solaris ld combination.

The Solaris SPARC assembler can't hanlde .8byte. So, i have to use .xword,
which isn't quite the same exact thing as .8byte.

So, this is what happens if i re-write the test32.S program for the Sun
SPARC assembler:

    ! test32-sun.S
    .data
    .align 8
    .global .gomp_critical_user_
    .comm .gomp_critical_user_, 64, 8

    .type .gomp_critical_user_,#object
    .size .gomp_critical_user_, 64

    .data
    .global __kmp_unnamed_critical_addr

__kmp_unnamed_critical_addr:
    .xword .gomp_critical_user_
    .type __kmp_unnamed_critical_addr,#object
    .size __kmp_unnamed_critical_addr, .-__kmp_unnamed_critical_addr

    .file "test32-sun.S"

address@hidden/builds/steleman/userland-s12-binutils-gas-24380705/components/binutils/build/sparcv9/gas][08/02/2016
6:49:34][536]>> /usr/bin/as -m32 -xarch=v8plusa test32-sun.S -o test32-sun.o
address@hidden/builds/steleman/userland-s12-binutils-gas-24380705/components/binutils/build/sparcv9/gas][08/02/2016
6:49:36][537]>> readelf -sW --relocs test32-sun.o 

Relocation section '.rela.data' at offset 0xf8 contains 1 entries:
 Offset     Info    Type                Sym. Value  Symbol's Name + Addend
00000004  00000303 R_SPARC_32             00000008   .gomp_critical_user_ + 0

Symbol table '.symtab' contains 5 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 00000000     0 FILE    LOCAL  DEFAULT  ABS test32-sun.S
     2: 00000000     0 SECTION LOCAL  DEFAULT    2 
     3: 00000008    64 OBJECT  GLOBAL DEFAULT  COM .gomp_critical_user_
     4: 00000000     8 OBJECT  GLOBAL DEFAULT    2 __kmp_unnamed_critical_addr

So, as you can see, the Sun SPARC assembler emitted a R_SPARC_32 relocation
for .gomp_critical_user_.

By comparison, GAS with my proposed patch emits this:

address@hidden/builds/steleman/userland-s12-binutils-gas-24380705/components/binutils/build/sparcv9/gas][08/02/2016
6:50:56][540]>> readelf -sW --relocs test32-new.o 

Relocation section '.rela.data' at offset 0x140 contains 1 entries:
 Offset     Info    Type                Sym. Value  Symbol's Name + Addend
00000000  00000617 R_SPARC_UA32           00000008   .gomp_critical_user_ + 0

Symbol table '.symtab' contains 8 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 00000000     0 FILE    LOCAL  DEFAULT  ABS test32.S
     2: 00000000     0 SECTION LOCAL  DEFAULT    1 
     3: 00000000     0 SECTION LOCAL  DEFAULT    2 
     4: 00000000     0 SECTION LOCAL  DEFAULT    4 
     5: 00000000     0 SECTION LOCAL  DEFAULT    5 
     6: 00000008    64 OBJECT  GLOBAL DEFAULT  COM .gomp_critical_user_
     7: 00000000     8 OBJECT  GLOBAL DEFAULT    2 __kmp_unnamed_critical_addr

But, you are absolutely right in saying that I should come up with test
cases and proposed patches for all the other possible 64-bit relocations
for 32-bit cases.

So, please stay tuned. :-)

And thank you very much for looking at this proposed patch so quickly!!

-- 
You are receiving this mail because:
You are on the CC list for the bug.