Re: [Patch,AVR]: Use EIND consistently

[Denis Chertykov <chertykov at gmail dot com>]

2011/10/21 Georg-Johann Lay <avr@gjlay.de>:
> This patch adds support to consistently use EIND.
>
> The compiler never sets this SFR but uses it in table jumps and EIJMP/EICALL
> instructions.
>
> Custom startup code could set EIND to an other value than 0 and the compiler
> should use EIND consistently given that EIND might not be zero.
>
> EIND != 0 will need support of custom linker script to locate jump pads in an
> other segment, but that's a different story.
>
> The patch undoes some changes from r179760 and introduces using EIND the other
> way round: Not trying to avoid EIND altogether and assume code is supposed to
> work in the lower segment only, but instead use EIND and not zero-reg when
> simulating indirect jump by means of RET.
>
> With this patch, the application may set EIND to a custom value and invent own
> linker script to place jump pads. ÂThe assertion is that EIND never changes
> throughout the application and therefore ISR prologue/epilogue need not care.
>
> With the gs() magic, code using indirect jumps works fine with that, e.g.
> - Indirect calls
> - Computed goto
> - Jumping to 1: in prologue_saves
>
> What does not work as expected is to jump to const_int addresses like
>
> int main()
> {
> Â ((void(*)(void))0)();
> Â return 0;
> }
>
> Instead, code must read
>
> extern void my_address (void);
>
> int main()
> {
> Â Âmy_address();
> Â Âreturn 0;
> }
>
> and compiled with, say -Wl,--defsym,my_address=0x20000, so that a jump pad is
> generated.
>
> Patch ok for trunk?
>
> Johann
>
> Â Â Â Â* config/avr/libgcc.S (__EIND__): New define to 0x3C.
> Â Â Â Â(__tablejump__): Consistently use EIND for indirect jump/call.
> Â Â Â Â(__tablejump_elpm__): Ditto.

Approved.

Denis.