[avr-gcc-list] RE: AVR-GCC-list Digest, Vol 52, Issue 10

[Mohamed Reda]

i wish to learn the c++ structure to be able to wright a project using AVR-GCC.
 
> Date: Sun, 10 May 2009 12:01:07 -0400
> From: address@hidden
> Subject: AVR-GCC-list Digest, Vol 52, Issue 10
> To: address@hidden
>
> Send AVR-GCC-list mailing list submissions to
> address@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
> or, via email, send a message with subject or body 'help' to
> address@hidden
>
> You can reach the person managing the list at
> address@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of AVR-GCC-list digest..."
>
>
> Today's Topics:
>
> 1. mcall-prologues completely broken for >128k (Sean D'Epagnier)
> 2. RE: mcall-prologues completely broken for >128k (Weddington, Eric)
> 3. Re: mcall-prologues completely broken for >128k (Sean D'Epagnier)
> 4. Re: mcall-prologues completely broken for >128k (Sean D'Epagnier)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 9 May 2009 13:36:21 -0600
> From: "Sean D'Epagnier" <address@hidden>
> Subject: [avr-gcc-list] mcall-prologues completely broken for >128k
> To: address@hidden
> Message-ID:
> <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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.
>
> Thanks,
> Sean
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 9 May 2009 21:08:18 -0600
> From: "Weddington, Eric" <address@hidden>
> Subject: RE: [avr-gcc-list] mcall-prologues completely broken for
> >128k
> To: "Sean D'Epagnier" <address@hidden>,
> <address@hidden>
> Message-ID:
> <address@hidden>
> Content-Type: text/plain; charset="us-ascii"
>
>
>
> > -----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.
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 9 May 2009 22:39:33 -0600
> From: "Sean D'Epagnier" <address@hidden>
> Subject: Re: [avr-gcc-list] mcall-prologues completely broken for
> >128k
> To: "Weddington, Eric" <address@hidden>
> Cc: address@hidden
> Message-ID:
> <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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.
> >
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 10 May 2009 00:26:27 -0600
> From: "Sean D'Epagnier" <address@hidden>
> Subject: Re: [avr-gcc-list] mcall-prologues completely broken for
> >128k
> To: "Weddington, Eric" <address@hidden>
> Cc: address@hidden
> Message-ID:
> <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> Here are some patches. Please take a look and tell me if what I did
> with setjmp makes any sense. I don't really use longjmp so it's not
> fully tested, and it is only to handle a case which is very difficult
> to create.
>
> I have tested the gcc patch and my program is working very well now.
>
> There is still a major issue of what to do in bootloaders. It appears
> that the trampolines do not get generated for bootloaders.. and how
> can they? For bootloaders the compiler should use eijmp and eicall
> and set EIND to the bootloader segment at startup. But what if
> longjmp is used and what if application code is called? I'm not sure
> what the best solution is here, but currently I'm just glad my
> bootloader doesn't need indirect jumps.
>
> Sean
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: avr-gcc-eijmp-eicall.patch
> Type: text/x-diff
> Size: 3583 bytes
> Desc: not available
> Url : http://lists.gnu.org/pipermail/avr-gcc-list/attachments/20090510/f80448c0/avr-gcc-eijmp-eicall.bin
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: avr-libc-extended-setjmp.patch
> Type: text/x-diff
> Size: 594 bytes
> Desc: not available
> Url : http://lists.gnu.org/pipermail/avr-gcc-list/attachments/20090510/f80448c0/avr-libc-extended-setjmp.bin
>
> ------------------------------
>
> _______________________________________________
> AVR-GCC-list mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>
>
> End of AVR-GCC-list Digest, Vol 52, Issue 10
> ********************************************

---

See all the ways you can stay connected to friends and family