RE: [avr-gcc-list] Function Address fixup missing?

[Stu Bell]

> I have a program for the AtMega2561 that is more that 128K 
> and that make use of function pointers. The compiler is 
> WinAvr as of March 13, 2009.
> 
> As I understood when a function body is in the upper 128K, 
> and the address of this function is taken, the compiler (or 
> linker) generates a small stub in the "trampoline" area in 
> lower memory that contains a jump to the function body.
> The "address of" operator then returns the address of this 
> stub, rather that the address of the function itself.
> This way an indirect jump through the pointer (only 16 bits) 
> ends up, being the EIND register always zero, to the stub, 
> which in turn makes a full jump to the function.

Trampolines work only for statically linked functions, not function
pointers.

This is a known bug and cannot easily be fixed.

The root of the problem is that GCC's architecture does not lend itself
to 24-bit entities.  As you noted, function pointers are 16 bits, which
limits the range to 128K of flash (since all AVR instructions are 2
bytes wide, the program counter addresses 2 byte words).

GCC could be modified to run with 32-bit (4 byte) pointers, but the
ATTiny folks would yell like mashed cats if that were done universally.
I suppose that a switch could be placed telling GCC whether to use 16
bit or 32 bit pointers, but then the avr-libc library would need to be
compiled both ways leading to problems of making sure that the correct
library is linked with the correct compiled source.

All of the above could be done.  However, the GCC team are notoriously
low on volunteers.  Interested in taking this project on?  I thought
not.

For the moment, the only solution is to place the target of all function
pointers in the bottom part of the ATMega2560/1's flash.  If you check
my post on FreeRTOS for the ATmega2560/1 on AVR Freaks
(http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=70387
) you will find that I describe how to place function pointer targets in
low flash.

I should point out that there *is* another fix for the problem:  I
understand the IAR and CodeVision have compilers capable of handling the
larger ATMega series.  Oh wait, those cost *money*.  Well, Cheap Fast
Good - choose two.

Best regards, 

Stu Bell 
DataPlay (DPHI, Inc.)