[Bug target/38549] [avr] eicall not properly set for > 128K program space

["johnstonj at inn-soft dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38549

johnstonj@inn-soft.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |johnstonj@inn-soft.com

--- Comment #5 from johnstonj@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.