https://sourceware.org/bugzilla/show_bug.cgi?id=20427
--- Comment #5 from Nick Clifton <nickc at redhat dot com> ---
Hi Stefan,
> So, this is what happens if i re-write the test32.S program for the Sun
> SPARC assembler:
> .comm .gomp_critical_user_, 64, 8
> 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
Interesting. I wonder if this is a bug in the Solaris assembler ?
Maybe it knows that a symbol's value can only ever be 32-bits, so in this
particular case the reloc will work. But what if the test really needed a
(non-zero) 64-bit value to be installed into the memory location.
For example, how does the Solaris assembler handle this:
.data
.global __kmp_unnamed_critical_addr
__kmp_unnamed_critical_addr:
.xword .gomp_critical_user_ + 0x1234567890
.type __kmp_unnamed_critical_addr,#object
.size __kmp_unnamed_critical_addr, .-__kmp_unnamed_critical_addr
Looking at the output for GAS, it seems that the addition in the reloc
is truncated:
00000000 R_SPARC_UA64 .gomp_critical_user_+0x34567890
This is not reported as an error, either, so presumably it is expected
behaviour. Which makes me think that your patch will be OK. But I would
like to know the results of your search for other 64-bit tests.
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-binutils
