RTOS/rtems
1
0
Fork 0
forked from Imagelibrary/rtems
Code Pull Requests Activity

Revert "bsps/powerpc: Fix potential relocation truncation"

Browse Source 
This reverts commit d9ff8b3e68.

It is not that simple:

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

On Fri, Jun 06, 2014 at 01:31:48PM +0200, Sebastian Huber wrote:
> On 2014-06-06 13:23, Sebastian Huber wrote:
> >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?
>
> Hm, sorry, it was surprisingly simple.  This works:
>
> "cmplwi cr0, rX, ppc_exc_lock_std@sdarel@l"
>
> I was not aware that you can add several @ in a row.

That is the wrong thing to use here.  sdarel@l translates to a VLE
reloc which applies to a split 16-bit field in VLE insns.

You want
 cmpwi cr0, rX, ppc_exc_lock_std@sdarel
to properly compare a 16-bit signed number from sym@sdarel.

Note that the assembler does error if you write something like
 cmplwi 3,-30000
or
 cmpwi 3,40000
so what the linker is now doing is extending this behaviour to link
time.
This commit is contained in:
Sebastian Huber
2014-06-06 14:54:37 +02:00
parent d9ff8b3e68
commit c1072919fa
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
c/src/lib/libcpu/powerpc/new-exceptions/bspsupport/ppc_exc_asm_macros.h
View File

@@ -168,7 +168,7 @@ ppc_exc_min_prolog_sync_\_NAME:
* if what's left compares against the 'ppc_exc_lock_std@sdarel' * if what's left compares against the 'ppc_exc_lock_std@sdarel'
* address offset then we have a match... * address offset then we have a match...
*/ */
cmplwi cr0, \_REG, ppc_exc_lock_std@sdarel@l cmplwi cr0, \_REG, ppc_exc_lock_std@sdarel
.endm .endm