[Bug target/45264] Stack corruption with any function using frame

[darkdragon2000 at hotmail dot com]

--- Comment #6 from darkdragon2000 at hotmail dot com  2010-08-13 22:30 
---
OK thanks, is the code I attached here OK?  I already submitted this to Atmel
also (#605725).  Last time I submitted a bug to them this is the reply I got
back:

Note that avr-gcc and avr-libC are open-source projects, which you may directly
report bugs
to (see http://www.nongnu.org/avr-libc/bugs.html).



(In reply to comment #5)
 Marking this bug as INVALID because the AVR Toolchain 3.0.0.207 is not an
 officially released toolchain, and only in beta.
 
 If you have any potential bugs, then please send to avr AT atmel DOT com, and
 please CC me. AFAIK, Atmel did not (or should have not) sent you to here. 
 
 When you do send a bug report, send a compilable test case that shows the bugs
 along with the command line you used, and especially show which device this is
 for.
 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45264

[Bug target/45264] New: Stack corruption with any function using frame

[darkdragon2000 at hotmail dot com]

With the beta AVR toolchain 3.0.0.207, the prologue for functions using a frame
has changed and is now causing stack corruption when an interrupt fires.  Take
for example a function which needs 5 bytes of frame.  This is how the frame is
setup in the function prologue:

Under WinAVR2010:
 a30:   df 93   pushr29
 a32:   cf 93   pushr28
 a34:   00 d0   rcall   .+0 ; 0xa36 
 a36:   00 d0   rcall   .+0 ; 0xa38 
 a38:   0f 92   pushr0
 a3a:   cd b7   in  r28, 0x3d   ; 61
 a3c:   de b7   in  r29, 0x3e   ; 62

AVR Toolchain 3.0.0.207:
+0507:   93DFPUSH  R29Push register on stack
+0508:   93CFPUSH  R28Push register on stack
+0509:   B7CDINR28,0x3D   In from I/O location
+050A:   B7DEINR29,0x3E   In from I/O location
+050B:   9725SBIW  R28,0x05   Subtract immediate from word
+050C:   BFDEOUT   0x3E,R29   Out to I/O location
+050D:   BFCDOUT   0x3D,R28 

The stack corruption occurs when an interrupt fires between addresses 0x50C and
0x50D in the example above since the stack pointer is only half updated.

I have submitted this as critical since it causes applications to crash
consistently.


-- 
   Summary: Stack corruption with any function using frame
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: darkdragon2000 at hotmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45264

[Bug target/45264] Stack corruption with any function using frame

[darkdragon2000 at hotmail dot com]

--- Comment #2 from darkdragon2000 at hotmail dot com  2010-08-12 17:52 
---
It's not a bug in the handler since when the interrupt fires at the point when
the stack pointer is invalid (right after 0x50c), the program counter gets
pushed onto the stack, which is an invalid location.

When I tried to submit a report with the vendor, they pointed me back here. 
Maybe this should go to AVRLiBC?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45264

[Bug target/45264] Stack corruption with any function using frame

[darkdragon2000 at hotmail dot com]

--- Comment #3 from darkdragon2000 at hotmail dot com  2010-08-12 23:56 
---
Created an attachment (id=21472)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21472action=view)
File which recreates the issue


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45264

[Bug target/45264] Stack corruption with any function using frame

[darkdragon2000 at hotmail dot com]

--- Comment #4 from darkdragon2000 at hotmail dot com  2010-08-12 23:56 
---
Created an attachment (id=21473)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21473action=view)
makefile


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45264

[Bug other/44940] New: XMEGA RAMPZ Initialization

[darkdragon2000 at hotmail dot com]

When compiling a bootloader for the XMEGA128 (starting address 0x2), RAMPZ
is initialized to 2 in the __do_copy_data section.  This has the effect that
any indirect register access will fail.

 For example the following code extract will result in the register NOT being
set to 0xCB when RAMPZ = 2.

20c6e: 2b ec   ldi r18, 0xCB   ; 203
20c70: e0 e5   ldi r30, 0x50   ; 80
20c72: f0 e0   ldi r31, 0x00   ; 0
20c74: 22 83   std Z+2, r18; 0x02

To recreate this, simply put OSC.XOSCCTRL = 0xCB; in the main function and link
to bootloader memory space.


-- 
   Summary: XMEGA RAMPZ Initialization
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: darkdragon2000 at hotmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44940