RE: [avr-gcc-list] avr-gcc 4.2.2 atmega 2561 issues

[Weddington, Eric]

Actually I need to find out if there is still a problem with this on WinAVR 
20081205.

Simon, what version are you using?

Eric 

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Stu Bell
> Sent: Tuesday, December 16, 2008 8:34 AM
> To: Simon Eatough; address@hidden
> Subject: RE: [avr-gcc-list] avr-gcc 4.2.2 atmega 2561 issues
> 
> I assume you are using the latest/greatest version (either WinAVR
> 20081205 or the equivalent).
> 
> I also came across this and I believe I wrote a bug report on 
> it.  IIRC,
> the issue is that the library was compiled with a switch that 
> tells the
> compiler to use a prologue routine rather than inlining the prologue.
> That makes sense for ATTinys but causes us in the mega2560 headaches.
> The problem is that the prologue routine, as you noted, assumes that
> it's current location is the proper "page" for the eijump.  To fix it
> permanently I think the prologue call would somehow have to encode the
> return address' page.  This is all from memory, so it may be wrong.
> 
> Again, IIRC, I solved it by re-arranging the code map to avoid the
> victim routines straddling the 128K boundary.  That can be done easily
> enough by re-arranging the list of objects handed to the linker. It
> links them in order that the object files are listed.
> 
> You can also download the source to avr-libc and compile it yourself
> using the appropriate flags.  Of course, you would need to do 
> that every
> time you updated the WinAVR/avr-libc stuff.
> 
> Unfortunately there is no simple fix to the problem.  Or 
> maybe there is,
> and I can't remember what I did.
> 
> Best regards, 
> 
> Stu Bell 
> DataPlay (DPHI, Inc.) 
> 
>  
> 
> > -----Original Message-----
> > From: address@hidden 
> > [mailto:address@hidden 
> > On Behalf Of Simon Eatough
> > Sent: Monday, December 15, 2008 7:50 PM
> > To: address@hidden
> > Subject: [avr-gcc-list] avr-gcc 4.2.2 atmega 2561 issues
> > 
> > Hi folks
> > I've got a project where the code has just crossed the 
> > dreaded 128k boundary. 
> > Specifically glibc straddles the boundary. 
> > I've got problems with the code crashing,  due i think to 
> > call of si_to_float in libgcc  which sets up the Z register 
> > for the eijmp in __prolog_saves__  ,but does not set EIND . 
> > causing the eijmp instruction to jump to the wrong address.
> > 
> > disassembly below.
> > 
> > si_to_float (SItype arg_a)
> > {
> >    1fee4:   a8 e0           ldi r26, 0x08   ; 8
> >    1fee6:   b0 e0           ldi r27, 0x00   ; 0
> >    1fee8:   e8 e7           ldi r30, 0x78   ; 120
> >    1feea:   ff ef           ldi r31, 0xFF   ; 255
> >    1feec:   0d 94 7f 04     jmp 0x208fe ; 0x208fe 
> > <__prologue_saves__+0x12>
> >    1fef0:   9b 01           movw    r18, r22
> >    1fef2:   ac 01           movw    r20, r24
> >   fp_number_type in;
> > 
> > /snip
> > 
> > 
> > 000208ec <__prologue_saves__>:
> >    208ec:   2f 92           push    r2
> >    208ee:   3f 92           push    r3
> >    208f0:   4f 92           push    r4
> >    208f2:   5f 92           push    r5
> >    208f4:   6f 92           push    r6
> >    208f6:   7f 92           push    r7
> >    208f8:   8f 92           push    r8
> >    208fa:   9f 92           push    r9
> >    208fc:   af 92           push    r10
> >    208fe:   bf 92           push    r11
> >    20900:   cf 92           push    r12
> >    20902:   df 92           push    r13
> >    20904:   ef 92           push    r14
> >    20906:   ff 92           push    r15
> >    20908:   0f 93           push    r16
> >    2090a:   1f 93           push    r17
> >    2090c:   cf 93           push    r28
> >    2090e:   df 93           push    r29
> >    20910:   cd b7           in  r28, 0x3d   ; 61
> >    20912:   de b7           in  r29, 0x3e   ; 62
> >    20914:   ca 1b           sub r28, r26
> >    20916:   db 0b           sbc r29, r27
> >    20918:   0f b6           in  r0, 0x3f    ; 63
> >    2091a:   f8 94           cli
> >    2091c:   de bf           out 0x3e, r29   ; 62
> >    2091e:   0f be           out 0x3f, r0    ; 63
> >    20920:   cd bf           out 0x3d, r28   ; 61
> >    20922:   19 94           eijmp
> > 
> > 
> > Wonder if there is a workaround for this ?
> > 
> > Cheers
> > Simon
> > 
> > 
> > --
> > Simon Eatough
> > Development Engineer
> > Pertronic Industries
> > Wellington NZ
> > 
> > 
> > _______________________________________________
> > AVR-GCC-list mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
> > 
> 
> 
> _______________________________________________
> AVR-GCC-list mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>