[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.
- [avr-gcc-list] mcall-prologues completely broken for >128k, Sean D'Epagnier, 2009/05/09
- RE: [avr-gcc-list] mcall-prologues completely broken for >128k,
Weddington, Eric <=
- Re: [avr-gcc-list] mcall-prologues completely broken for >128k, Sean D'Epagnier, 2009/05/10
- Re: [avr-gcc-list] mcall-prologues completely broken for >128k, Sean D'Epagnier, 2009/05/10
- RE: [avr-gcc-list] mcall-prologues completely broken for >128k, Weddington, Eric, 2009/05/12
- Re: [avr-gcc-list] mcall-prologues completely broken for >128k, Sean D'Epagnier, 2009/05/12
- Re: [avr-gcc-list] mcall-prologues completely broken for >128k, Anatoly Sokolov, 2009/05/13
- Re: [avr-gcc-list] mcall-prologues completely broken for >128k, Sean D'Epagnier, 2009/05/13
- Re: [avr-gcc-list] mcall-prologues completely broken for >128k, Anatoly Sokolov, 2009/05/13
- Re: [avr-gcc-list] mcall-prologues completely broken for >128k, Sean D'Epagnier, 2009/05/13
- Re: [avr-gcc-list] mcall-prologues completely broken for >128k, Dmitry K., 2009/05/13
- Re: [avr-gcc-list] mcall-prologues completely broken for >128k, Anatoly Sokolov, 2009/05/13