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

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #11 from Alan Modra  ---
As per comment #9.

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

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

[nickc at redhat dot com]

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

--- Comment #10 from Nick Clifton  ---
Hi Guys,

  Right - I think that it is now obvious that Stefan's patch is correct, so 
  I have checked it in.  It may be however that the patch does not go far
  enough - there may be other 64-bit relocs that need curtailing - but I am
  going to wait until there is a test that demonstrates the problem and 
  verifies any proposed solution.

Cheers
  Nick

-- 
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

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Nick Clifton :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=024425668d120663a73913352df701c8f0aea316

commit 024425668d120663a73913352df701c8f0aea316
Author: Stefan Trleman 
Date:   Thu Aug 4 14:57:23 2016 +0100

Fix generation of relocs for 32-bit Sparc Solaris targets.

PR gas/20427
* config/tc-sparc.c (cons_fix_new_sparc): Prevent the generation
of 64-bit relocation types when assembling for a 32-bit Solaris
target.

-- 
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

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from Rainer Orth  ---
Two more data points in addition to what Ali has discovered:

* In addition to gas emitting those 64-bit relocs for 32-bit objects, I
  tried to build libtest32.so from Stefan's testcase with mainline gcc
  configured to use both gas and gld on sparc-sun-solaris2.12, which
  worked just fine (at least there was no error), unlike with ld, and
  produces

Relocation Section:  .rela.dyn
  index  type   offset value  addend  section symbol
[...]
[9]  R_SPARC_640x107b0 0   0  .data  
.gomp_critical_user_


* However, according to my reading of the glibc sources, only the
  sparc64 runtime linker, /lib64/ld-linux.so.2, accepts the R_SPARC_64
  reloc, while the sparc32 one, /lib/ld-linux.so.2 doesn't:

  sysdeps/sparc/sparc64/dl-machine.h (elf_machine_rela) accepts and
  handles it, while sysdeps/sparc/sparc32/dl-machine.h
  (elf_machine_rela) doesn't and errors out with _dl_reloc_bad_type
  printing "unexpected reloc type 0x32", just as Solaris ld.so.1 aborts
  with

ld.so.1: main32: fatal: relocation error: file /homes/ro/rel64/libtest32.so: 
symbol .gomp_critical_user_: invalid relocation type for ELFCLASS32: 32

  when trying to run main32.

  I don't have a Linux/SPARC machine around, so I cannot try this for
  real and may well be wrong in my reading.

If that turns out to be true, though, both runtime linkers are correct
(and consistent :-) while gas and gld get it wrong.

Rainer

-- 
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

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

[ali_swbugzilla at emvision dot com]

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

Ali Bahrami  changed:

   What|Removed |Added

 CC||ali_swbugzilla at emvision dot 
com

--- Comment #7 from Ali Bahrami  ---
We think it's not a linker bug. The 32 and 64-bit
sparc platform ABIs are distinct, and here, we're talking
about relocations defined for 64-bit objects, but not for
32-bit ones. The error from ld seems legit, and is intended
to catch this case.

The 2 tables of sparc relocations (32 and 64-bit) can be
found here:

   
https://docs.oracle.com/cd/E53394_01/html/E54813/chapter6-54839.html#OSLLGchapter6-62988

This question wouldn't come up if we were discussing x86,
where the 32 and 64-bit relocations are pretty different, but
with sparc, where the 64-bit case is essentially an extension of
the 32-bit case, that's probably less obvious.

Just to be sure, I checked with our resident sparc architecture
expert, and he told us:

I'm not exactly sure what the question is.

The relocations are for late binding
of the value of a symbol.
Symbol values in a 32-bit program
cannot be larger than 32-bits, AFAIK.

Now relocations are a little more complicated,
because they encode an expression.
So, we could have relocations that
encode an expression that is larger
than 32-bits for a 32-bit program.
But there has been no need for them,
so they were never created, AFAIK.

It would certainly be possible
to create some 64-bit relocation expressions
for 32-bit programs.
I would want to see some better justification
before creating them, though.
And some assembler syntax might be necessary
to disambiguate which relocation should be used
in some circumstances. 

Which I will simplify to "we haven't needed that relocation
for 32-bit sparc, so it doesn't exist".

Another engineer here mentioned the following:

For what it's worth, Go's internal linker handles this by
generating two relocations internally -- one for the lower
half of the 64-bit value and one for the upper half of the
 64-bit value.

This tends to work out nicely since you have to load each half
separately anyway:

// R_ADDRSPARC64LO (only used on sparc64) resolves to low 32bits of a
// 64-bit address, by loading the address into a register with two
instructions.
R_ADDRSPARC64LO
// R_ADDRSPARC64HI (only used on sparc64) resolves to high 32bits of a
// 64-bit address, by loading the address into a register with two
instructions.
R_ADDRSPARC64HI 

That squares with Nick's earlier comment

Does it, for example, produce two 32-bit relocs, one
for the lower 32-bits and one for the upper 32-bits ?

-- 
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

[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 #6 from Stefan Teleman  ---
If i change the test case for the Sun assembler:

__kmp_unnamed_critical_addr:
.xword .gomp_critical_user_ + 0x1234567890

i get this:

[steleman@hoggle][/builds/steleman/userland-s12-binutils-gas-24380705/components/binutils/build/sparcv9/gas][08/02/2016
7:30:35][544]>> /usr/bin/as -m32 -xarch=v8plusa test32-sun.S -o test32-sun.o
/usr/bin/as: "test32-sun.S", line 14: warning: value does not fit in 32 bits
[steleman@hoggle][/builds/steleman/userland-s12-binutils-gas-24380705/components/binutils/build/sparcv9/gas][08/02/2016
7:30:43][545]>> readelf -sW --relocs test32-sun.o 

Relocation section '.rela.data' at offset 0xf8 contains 1 entries:
 Offset InfoTypeSym. Value  Symbol's Name + Addend
0004  0303 R_SPARC_32 0008   .gomp_critical_user_ +
34567890

Symbol table '.symtab' contains 5 entries:
   Num:Value  Size TypeBind   Vis  Ndx Name
 0:  0 NOTYPE  LOCAL  DEFAULT  UND 
 1:  0 FILELOCAL  DEFAULT  ABS test32-sun.S
 2:  0 SECTION LOCAL  DEFAULT2 
 3: 000864 OBJECT  GLOBAL DEFAULT  COM .gomp_critical_user_
 4:  8 OBJECT  GLOBAL DEFAULT2 __kmp_unnamed_critical_addr

Same as GAS, but the Sun assembler emits a warning.

Which now creates a new and interesting question that i am going to run
by the Solaris linker people: isn't this a Solaris rtld bug, in final
analysis?

I will ask the linker folks and i will come up with more test cases
for the other relocations.

Thank you very much!

--Stefan

-- 
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

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

[nickc at redhat dot com]

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

--- Comment #5 from Nick Clifton  ---
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 InfoTypeSym. Value  Symbol's Name + Addend
> 0004  0303 R_SPARC_32 0008   .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:

   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
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

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

[Nick Clifton]

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 InfoTypeSym. Value  Symbol's Name + Addend
> 0004  0303 R_SPARC_32 0008   .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:

   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


___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[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  ---
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 InfoTypeSym. Value  Symbol's Name + Addend
0004  0303 R_SPARC_32 0008   .gomp_critical_user_ + 0

Symbol table '.symtab' contains 5 entries:
   Num:Value  Size TypeBind   Vis  Ndx Name
 0:  0 NOTYPE  LOCAL  DEFAULT  UND 
 1:  0 FILELOCAL  DEFAULT  ABS test32-sun.S
 2:  0 SECTION LOCAL  DEFAULT2 
 3: 000864 OBJECT  GLOBAL DEFAULT  COM .gomp_critical_user_
 4:  8 OBJECT  GLOBAL DEFAULT2 __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 InfoTypeSym. Value  Symbol's Name + Addend
  0617 R_SPARC_UA32   0008   .gomp_critical_user_ + 0

Symbol table '.symtab' contains 8 entries:
   Num:Value  Size TypeBind   Vis  Ndx Name
 0:  0 NOTYPE  LOCAL  DEFAULT  UND 
 1:  0 FILELOCAL  DEFAULT  ABS test32.S
 2:  0 SECTION LOCAL  DEFAULT1 
 3:  0 SECTION LOCAL  DEFAULT2 
 4:  0 SECTION LOCAL  DEFAULT4 
 5:  0 SECTION LOCAL  DEFAULT5 
 6: 000864 OBJECT  GLOBAL DEFAULT  COM .gomp_critical_user_
 7:  8 OBJECT  GLOBAL DEFAULT2 __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

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

[nickc at redhat dot com]

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

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #3 from Nick Clifton  ---
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 ?

  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 ?]

Cheers
  Nick

-- 
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

[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 #2 from Stefan Teleman  ---
All gas tests on Solaris SPARC pass after applying the proposed patch.

-- 
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

[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

Stefan Teleman  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org,
   ||stefan.teleman at gmail dot com

-- 
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

[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

Stefan Teleman  changed:

   What|Removed |Added

 CC||stefan.teleman at oracle dot 
com

--- Comment #1 from Stefan Teleman  ---
Created attachment 9416
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9416=edit
proposed patch -- tc-sparc.c.patch

Proposed patch. 

This patch applies cleanly to Binutils 2.25.1 and 2.26.1

-- 
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