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

As you please.

Denis.