Re: [avr-gcc-list] mcall-prologues completely broken for >128k

[Sean D'Epagnier]

I got myself a little confused here..

I was using gcc 4.2.2, and an older binutils at first because it has
superior code size.. however this version really is broken for > 128k
parts, and I'm not sure why.. don't care.

Somewhere along the way I set EIND to a nonzero value in my code and
forgot about it, then I had issues with -mcall-prologues with the
newer gcc.  If you don't set EIND at all, I believe the current gcc is
ok.

I managed to modify gcc to set EIND correctly in the call prologue so
that a trampoline entree is no longer needed for every function that
gets prologues_saved which reduced 75 trampolines from my program.
Unfortunately this actually slightly increased code size because 2
bytes are added to all the functions that get prologues_saved, and
there was no exception for the lower 128k which don't need trampolines

So.. I don't think using the indirect register really helps much..
there are various ways I can handle things, but no clear winner, and
it's looking like 100 bytes or less difference at most.  If we had a
part with 1meg of flash or more, it might start to matter more and it
could be changed.

Instead I just converted gcc to only emit icall and ijmp instead of
eicall and eijmp.  This seems to work well, and avoids the problem of
EIND not being set right.  The only place now that uses eijmp is in
setjmp.S  This is good because even in the newest gcc, if EIND was set
by a longjmp, then a function is called with prologue saves.. or even
a function pointer or address label is invoked, then the program would
crash.  This is fixed now.

I am still a little worried that in the middle of a longjmp, an
interrupt goes off between setting EIND and eijmp, and this interrupt
sets EIND to a different value.  It would still cause a crash.  This
is only if you use longjmp in both program and interrupt handler.  The
solution is to guard it.  I'll have a patch for it too.

Sean


On 5/9/09, Weddington, Eric <address@hidden> wrote:
>
>
>> -----Original Message-----
>> From:
>> address@hidden
>> [mailto:address@hidden
>> org] On Behalf Of Sean D'Epagnier
>> Sent: Saturday, May 09, 2009 1:36 PM
>> To: address@hidden
>> Subject: [avr-gcc-list] mcall-prologues completely broken for >128k
>>
>> Hi,  I originally thought my extensive used of the gcc extension
>> "Address labels" was the cause of my problems.  After inspection of
>> the assembly I realized that they worked perfectly via the trampoline
>> mechanism..  so what was the problem?
>>
>> I found that prologue_saves calls eijmp at the end, which makes sense,
>> it gets back to the function it was in.  However, the EIND register is
>> not set which means it jumps to the wrong section if the function was
>> in the upper section.
>>
>> I verified it by recompiling everything (including avr-libc) without
>> -mcall_prologues and the program seems to run.. (before there was no
>> luck)
>>
>> This issue is pretty easy to fix.. I can set EIND before jumping to
>> prologue_saves.. but this would break when the next eijmp or eicall
>> instruction is executed  if I don't set EIND back to 0.
>>
>> The thing confusing me the most right now, is why gcc currently emits
>> eijmp or eicall at all.  Since EIND is _never_ set, why did someone go
>> to all the trouble to make gcc emit eijmp and eicall?  I want to
>> change gcc to use ijmp and icall always.. then in libgcc.S use eijmp,
>> and set EIND in prologue_saves and I won't have to bother restoring
>> it.
>>
>> If I'm confused about something, or there is a better explanation, let
>> me know.  I'm going to modify gcc and have a patch for this soon.
>
> Known issue. There is a bug report in the WinAVR bug database about it (EIND
> not being set correctly). I have recently changed avr-libc (in HEAD and 1.6
> branch) to compile the libs without -mcall-prologues because I ran into this
> very problem.
>
> A patch to GCC to fix the EIND issue would be *very* welcome and I would
> include it in the next WinAVR release.
>