>> 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.
Is this a thing to back port?
Johann
