http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38549
johnst...@inn-soft.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |johnst...@inn-soft.com
--- Comment #5 from johnst...@inn-soft.com 2010-11-02 20:25:05 UTC ---
I can confirm this is indeed a problem. I am developing a bootloader for
ATxmega128A1 (128 KB app flash + 8 KB bootloader = 136 KB flash total). My
code:
#define PROG_START 0x0000
(*((void(*)(void))PROG_START))(); //jump
This emits the following:
# Notice on reset, EIND register is written to a 1 as shown here.
# I searched the entire emitted disassembly and found no other
# reference to the I/O address for EIND.
000202e0 <__ctors_end>:
...
202ec: 01 e0 ldi r16, 0x01 ; 1
202ee: 0c bf out 0x3c, r16 ; 60
# Notice that Z is set to 0, as expected. However, EIND is not
# set to 0 and so the processor attempts to do the jump to
# the location specified by EIND == 1 and Z == 0, which isn't a valid
# place to jump to.
(*((void(*)(void))PROG_START))(); //jump
20590: e0 e0 ldi r30, 0x00 ; 0
20592: f0 e0 ldi r31, 0x00 ; 0
20594: 19 95 eicall
Presumably this will come up much more frequently now that the ATxmega
processors are available: all of these have so much flash that I would imagine
this will be a frequent problem.
I assume the problem happens with EIJMP which also uses EIND.
I notice that eicall / eijmp are used in libgcc.s. I wouldn't be surprised if
there are bugs there, too - but did not investigate further.
My fix is simple; just set EIND = 0 before my jump. However it leaves little
faith in my compiler for the application itself, since I don't know if it will
work reliably on AVR with large flash space for all jumps and calls, etc.
