This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 32-bit PowerPC sdata linker problem

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

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  :
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]