[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Weddington, Eric
Subject: RE: [avr-gcc-list] mcall-prologues completely broken for >128k
Date: Sat, 9 May 2009 21:08:18 -0600


> -----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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]