[Bug ld/20989] Every 64-bit Solaris 12/SPARC executable dies with SIGILL

2017-01-02 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20989

Alan Modra  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC|amodra at gmail dot com|
 Resolution|--- |FIXED
   Assignee|unassigned at sourceware dot org   |amodra at gmail dot com
   Target Milestone|--- |2.28

--- Comment #7 from Alan Modra  ---
Fixed

-- 
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 ld/20989] Every 64-bit Solaris 12/SPARC executable dies with SIGILL

2017-01-02 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20989

--- Comment #6 from cvs-commit at gcc dot gnu.org  ---
The binutils-2_28-branch branch has been updated by Alan Modra
:

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

commit 567e353f0e5d192b04f6b79e73dc14c5a74983c5
Author: Alan Modra 
Date:   Mon Jan 2 22:06:28 2017 +1030

PR20989, sparc GOT sequence optimisation

PR ld/20989
* elfxx-sparc.c (gdop_relative_offset_ok): New function.
(_bfd_sparc_elf_relocate_section): Use it to validate GOT
indirect to GOT pointer relative code edit.

-- 
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 ld/20989] Every 64-bit Solaris 12/SPARC executable dies with SIGILL

2017-01-02 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20989

--- Comment #5 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Alan Modra :

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

commit 5b86074c4a84e32ca55a6c72c5fca45d97dc9374
Author: Alan Modra 
Date:   Mon Jan 2 22:06:28 2017 +1030

PR20989, sparc GOT sequence optimisation

PR ld/20989
* elfxx-sparc.c (gdop_relative_offset_ok): New function.
(_bfd_sparc_elf_relocate_section): Use it to validate GOT
indirect to GOT pointer relative code edit.

-- 
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 ld/20989] Every 64-bit Solaris 12/SPARC executable dies with SIGILL

2016-12-26 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20989

--- Comment #4 from Alan Modra  ---
Created attachment 9724
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9724=edit
lightly tested fix

It is a bug in optimisation of sequences loading addresses from the GOT.  You
can't convert a GOT indirect load to GOT relative when the relative offset is
outside the range of possible sethi, xor values.  This happens with
-Ttext=0x1 which results in your gld testcase having
_GLOBAL_OFFSET_TABLE_ = 0x100100a10.  The relative offset to zero, the proper
value for the undefined weak symbol, is too large.

-- 
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 ld/20989] Every 64-bit Solaris 12/SPARC executable dies with SIGILL

2016-12-23 Thread ro at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20989

--- Comment #3 from Rainer Orth  ---
Created attachment 9722
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9722=edit
input objects and executables

-- 
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 ld/20989] Every 64-bit Solaris 12/SPARC executable dies with SIGILL

2016-12-23 Thread ro at CeBiTec dot Uni-Bielefeld.DE
https://sourceware.org/bugzilla/show_bug.cgi?id=20989

--- Comment #2 from Rainer Orth  ---
> --- Comment #1 from Alan Modra  ---
> How is crt1.o testing that __start_crt_compiler is undefined?  I'm talking
> about an "if (foo)" test used in a call to a weak function:
>   if (foo)
> foo ();

You've got this (I'm attaching both the crt1.o and empty-ld and
empty-gld executables for reference) in crt1.o:

crt1.o:

cc  __start_crt+0x4c:   2f 00 00 00  sethi %hi(0x0), %l7
d0  __start_crt+0x50:   f4 74 60 00  stx   %i2, [%l1]
d4  __start_crt+0x54:   ac 1d e0 00  xor   %l7, 0x0, %l6
d8  __start_crt+0x58:   ea 5c 00 16  ldx   [%l0 + %l6], %l5
dc  __start_crt+0x5c:   02 c5 40 09  brz,pn%l5, +0x24   
<__start_crt+0x80>

^ offsets (in hex) from the beginning of .text to allow matching with
  the relocs below.

  This is the

  if (__start_crt_compiler)
__start_crt_compiler ();

  part ...

e0  __start_crt+0x60:   91 3e 20 00  sra   %i0, 0x0, %o0
e4  __start_crt+0x64:   40 00 00 00  call  +0x0 
<__start_crt+0x64>

  ... and here are the corresponding relocs.

   [17]  R_SPARC_GOTDATA_OP_HIX220xcc 0  0  .text
__start_crt_compiler
   [18]  R_SPARC_GOTDATA_OP_LOX100xd4 0  0  .text
__start_crt_compiler
   [19]  R_SPARC_GOTDATA_OP  0xd8 0  0  .text
__start_crt_compiler
   [20]  R_SPARC_WPLT30  0xe4 0  0  .text
__start_crt_compiler

When single-stepping through this part of empty-ld (ld output), I find:

__start_crt+0x4c:   2f 00 00 00  sethi %hi(0x0), %l7
__start_crt+0x50:   f4 74 60 00  stx   %i2, [%l1]
__start_crt+0x54:   ac 1d e0 08  xor   %l7, 0x8, %l6
__start_crt+0x58:   ea 5c 00 16  ldx   [%l0 + %l6], %l5
__start_crt+0x5c:   02 c5 40 09  brz,pn%l5, +0x24   
<__start_crt+0x80>
__start_crt+0x60:   91 3e 20 00  sra   %i0, 0x0, %o0
__start_crt+0x64:   40 00 00 00  call  +0x0 
<__start_crt+0x64>

__start_crt+0x48:brnz,pn   %l2, 0x10b94 <__start_crt+0x54>

(gdb) p/x $l2
$5 = 0x7b08

__start_crt+0x4c:sethi  %hi(0), %l7
__start_crt+0x54:xor  %l7, 8, %l6
__start_crt+0x58:ldx  [ %l0 + %l6 ], %l5
__start_crt+0x5c:brz,pn   %l5, 0x10bc0 <__start_crt+0x80>

(gdb) p/x $l5
$4 = 0x0

  I.e. __start_crt_compiler is 0 and the branch is taken, skipping the
  call.

__start_crt+0x60:sra  %i0, 0, %o0
__start_crt+0x80:sethi  %hi(0x10), %i3

On the other hand, with the gld-produced executable, I get

__start_crt+0x4c:   2f 00 04 02  sethi %hi(0x100800), %l7
__start_crt+0x50:   f4 74 60 00  stx   %i2, [%l1]
__start_crt+0x54:   ac 1d fd f0  xor   %l7, -0x210, %l6
__start_crt+0x58:   aa 04 00 16  add   %l0, %l6, %l5
__start_crt+0x5c:   02 c5 40 09  brz,pn%l5, +0x24   
<__start_crt+0x80>
__start_crt+0x60:   91 3e 20 00  sra   %i0, 0x0, %o0
__start_crt+0x64:   7f ff fe 57  call  -0x6a4<0x1>

__start_crt+0x48:brnz,pn   %l2, 0x10694 <__start_crt+0x54>

(gdb) p/x $l2
$4 = 0x79d8

__start_crt+0x4c:sethi  %hi(0x100800), %l7
__start_crt+0x54:xor  %l7, -528, %l6
__start_crt+0x58:add  %l0, %l6, %l5
__start_crt+0x5c:brz,pn   %l5, 0x106c0 <__start_crt+0x80>

(gdb) p/x $l5
$6 = 0x1

__start_crt+0x60:sra  %i0, 0, %o0
__start_crt+0x64:call  0x1

  I.e. __start_crt_compiler is non-NULL, the call is taken, but the
  destination is invalid, leading to the SIGILL.

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 ld/20989] Every 64-bit Solaris 12/SPARC executable dies with SIGILL

2016-12-22 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20989

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #1 from Alan Modra  ---
How is crt1.o testing that __start_crt_compiler is undefined?  I'm talking
about an "if (foo)" test used in a call to a weak function:
  if (foo)
foo ();

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