Dear All,

I think I found a bug in msp430-gcc related to
calls where R1 is used. This bug was reported as 
fixed, but I think there is still a problem.

my OS: CentOS release 4.5

I build my own toolchain using:
- binutils-2.18 from ftp://sources.redhat.com/pub/binutils/releases/
- gcc-3.2.3 from ftp://gcc.gnu.org/pub/gcc/releases/
- patch files gcc-3.3 from http://mspgcc.cvs.sourceforge.net/mspgcc/gcc/
- msp430-libc from mspgcc.cvs.sourceforge.net:/cvsroot/mspgcc

-------------------------------------------------------------
my C program (msp430-gcc -O2 -E main.c > main.i):

# 1 "main.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "main.c"

void _main(void){

        typedef short (*fn_ptr)(void);

        unsigned short asm_program[] = {
                0x4130  // RET
        };

        ((fn_ptr)asm_program)();
}

-------------------------------------------------------------
and the compiled assembler code (msp430-gcc -O2 -S main.c -dp):

        .file   "main.c"
        .arch msp430x110

        .text
        .p2align 1,0
.global _main
        .type   _main,@function
/***********************
 * Function `_main'
 ***********************/
_main:
/* prologue: frame size = 2 */
.L__FrameSize__main=0x2
.L__FrameOffset__main=0x2
        sub     #2, r1  ;       2, fpn 0
/* prologue end (size=1) */
        mov     #llo(16688), @r1         ;  22  *movhi3/4       [length = 3]
        call    r1       ;  14  *call_value_insn/1      [length = 1]
/* epilogue: frame size=2 */
        add     #2, r1
        ret
/* epilogue end (size=2) */
/* function _main size 7 (4) */
.Lfe1:
        .size   _main,.Lfe1-_main
/********* End of function ******/


/*********************************************************************
 * File main.c: code size: 7 words (0x7)
 * incl. words in prologues: 1, epilogues: 2
 *********************************************************************/

-------------------------------------------------------------
As you can see the "asm_program" is copied to @SP
and then call using "CALL R1", which makes no sense,
because CALL R1 would execute the return address which
was placed onto stack before. I found the same R1 call
offset problem when CALL X(R1) is used. In this case
X is calculated wrong and should be X+2.

Hope someone can help me because I'm not able to fix
msp430-gcc myself ... I tried it ;-)

Best regards,
Maik

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

Reply via email to