2011/10/21 Georg-Johann Lay <a...@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.
>
> Is this a thing to back port?
>
As you please.
Denis.
