This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: 32-bit PowerPC sdata linker problem
- From: Sebastian Huber <sebastian dot huber at embedded-brains dot de>
- To: binutils at sourceware dot org
- Date: Fri, 06 Jun 2014 13:23:43 +0200
- Subject: Re: 32-bit PowerPC sdata linker problem
- Authentication-results: sourceware.org; auth=none
- References: <53918356 dot 3040102 at embedded-brains dot de> <20140606105420 dot GH5592 at bubble dot grove dot modra dot org>
On 2014-06-06 12:54, Alan Modra wrote:
On Fri, Jun 06, 2014 at 11:01:10AM +0200, Sebastian Huber wrote:
I performed a git bisect and found this:
93d1b056cb396d6468781fe0e40dd769891bed32 is the first bad commit
commit 93d1b056cb396d6468781fe0e40dd769891bed32
Author: Alan Modra <amodra@gmail.com>
Date: Tue May 20 11:42:42 2014 +0930
Rewrite ppc32 backend .sdata and .sdata2 handling
Hmm, I'm surprised that your git bisect found this patch. Was
_SDA_BASE_ set differently before this?
A diff -u map.ok map.error yields:
@@ -6549,10 +6550,11 @@
0x0000000000008000 PROVIDE (_SDA_BASE_, 0x8000)
*(.sdata .sdata.* .gnu.linkonce.s.*)
.sdata 0x00000000000d7c00 0x0
/opt/rtems-4.11/lib64/gcc/powerpc-rtems4.11/4.8.3/m603e/ecrti.o
- 0x00000000000d7c00 _SDA_BASE_
0x00000000000d7c00 __SDATA_START__
.sdata 0x00000000000d7c00 0x4
/opt/rtems-4.11/lib64/gcc/powerpc-rtems4.11/4.8.3/m603e/crtbegin.o
0x00000000000d7c00 __dso_handle
+ 0x00000000000dfc00 _SDA_BASE_
+ .sdata 0x00000000000d7c04 0x0
/opt/rtems-4.11/lib64/gcc/powerpc-rtems4.11/4.8.3/m603e/crtbegin.o
.sdata 0x00000000000d7c04 0x4c b-br_uid/init.o
0x00000000000d7c0c rtems_shell_Initial_aliases
0x00000000000d7c14
_RTEMS_tasks_Initialize_user_tasks_p
0x00000000000dfc00 _SDA_BASE_
0x00000000000d7f78 ppc_exc_lock_std
4b8: 28 05 00 00 cmplwi r5,0
4ba: R_PPC_SDAREL16 ppc_exc_lock_std
ppc_exc_lock_std@sdarel will be calculating 0xd7f78 - 0xdfc00
which is 0xf...fff8378, and that falls foul of
commit 86c9573369616e7437481b6e5533aef3a435cdcf
Author: Alan Modra <amodra@gmail.com>
Date: Sat Mar 8 13:05:06 2014 +1030
Better overflow checking for powerpc32 relocations
cmplwi has an *unsigned* 16-bit field, and we now check the overflow
properly.
I wonder how many more of these we'll hit, and whether the uproar will
be enough that I'll be forced to relax the checks?
Ok, so this "cmplwi cr0, rX, ppc_exc_lock_std@sdarel" is illegal, since
ppc_exc_lock_std@sdarel is signed and the immediate is unsigned 16-bit? The
assembler doesn't issue a warning about this.
Exists there a way to rescue this cmplwi hack without relaxing the overflow checks?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.