Changeset d9ff8b3e in rtems


Ignore:
Timestamp:
Jun 6, 2014, 11:35:56 AM (7 years ago)
Author:
Sebastian Huber <sebastian.huber@…>
Branches:
4.11, 5, master
Children:
c1072919
Parents:
dc44de7
git-author:
Sebastian Huber <sebastian.huber@…> (06/06/14 11:35:56)
git-committer:
Sebastian Huber <sebastian.huber@…> (06/06/14 11:39:55)
Message:

bsps/powerpc: Fix potential relocation truncation

See also

https://sourceware.org/ml/binutils/2014-06/msg00059.html

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@…>
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?

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@…>
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?

File:
1 edited

Legend:

Unmodified
Added
Removed
Note: See TracChangeset for help on using the changeset viewer.