>>>> 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?
>
> As you please.
>
> Denis.
It's here:
http://gcc.gnu.org/viewcvs?view=revision&revision=180303
Opened PR50820 for this.
Johann
