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"
[steleman@hoggle][/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
[steleman@hoggle][/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:
[steleman@hoggle][/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.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
