[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] mcall-prologues completely broken for >128k

From: Anatoly Sokolov
Subject: Re: [avr-gcc-list] mcall-prologues completely broken for >128k
Date: Wed, 13 May 2009 23:33:25 +0400

----- Original Message ----- From: "Sean D'Epagnier" <address@hidden>
To: "Anatoly Sokolov" <address@hidden>
Cc: "Weddington, Eric" <address@hidden>; <address@hidden>
Sent: Wednesday, May 13, 2009 6:35 PM
Subject: Re: [avr-gcc-list] mcall-prologues completely broken for >128k

On 5/13/09, Anatoly Sokolov <address@hidden> wrote:

On 5/12/09, Weddington, Eric <address@hidden> wrote:
I don't understand what you're doing here.

You've completely removed EIJMP from gcc.

That is correct.  It is better for gcc not to use this instruction.

This prevent using indirect function call in bootloader code for >128KB
FLASH devices.

Well as it stands now, gcc emits eijmp and eicall, but never sets
EIND, so if EIND is non-zero, then the call will most likely fail.

avr-libc/crt1/gcrt1.S :

.section .init0,"ax",@progbits
        .weak   __init
;       .func   __init
#ifdef __AVR_3_BYTE_PC__
        ldi     r16, hh8(pm(__vectors))
        out     _SFR_IO_ADDR(EIND), r16
#endif  /* __AVR_3_BYTE_PC__ */

This code set EIND to third byte of '__vectors' address.

1. This code is not clear, it is better use start address of *(.trampolines) section instead of '__vectors' . 2. More logical to move this code from crt1/gcrt1.S to gcc\config\avr\libgcc.S. Btcause the GCC uses EIND internally, then it must initialize its.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]