Bug in avr-gdb? was:Re: [avr-gcc-list] AVR simulator and interrupts

[Klaus Rudolph]

Hi James,

I could rproduce the problem also with actual simulavr.
After traceing through the gdb output I could found
a senseless continue command which is send from gdb to simulator.
The result is endless running of simulavr which is exact what the 
gdb wants but what is not what the user want from gdb :-)


I think we have a bug in gdb for avr.

Whats to do to reproduce the results:

Use the "new" simulavr, could be found under
http://home.comcast.net/~Bill5107/
Version 0.7.

Take the two attateched files test.c/test.elf. The elf is also attatched
that we have same results with differnt compiler versions and c-libs.

start simulavr:
>simulavr -g -dat90s8515 -ttrace -G >  gdbtrace 2>&1 &

if you want a online view display the results in differnt terminals:
>tail -f gdbtrace
>tail -f trace

start ddd  
>ddd --debugger avr-gdb
and enter the commands:

gdb>file test.elf
gdb>target remote localhost:1212
gdb>load
gdb>break main
gdb>cont

After running into first breakpoint remove the breakpoint
and do single steps until __vector in 0x0e is reached.

gdb> step
...
gdb> step
0x0000000e in __vectors ()

if you now do another step the simulator runs endless. That is not what we
want here I think.
What the gdb is sending to simulavr:

Sent: $e0a0e6b0e0e8ebf0e003c0c89531960d92a036b107d1f710e0#64
gdb -> Ack
Recv: "$s#73" 
Ack -> gdb
Sent: $T0520:02;21:5d02;22:94000000;#2b
******** <<<< here we are in the irq handler (0x94)
gdb -> Ack
Recv: "$m94,27#6f"
Ack -> gdb
Sent:
$1f920f920fb60f9211248f93809160008095809360008f910f900fbe0f901f901895ffcfffffff#3f
gdb -> Ack
Recv: "$mbb,19#c7"
Ack -> gdb
Sent: $ffffffffffffffffffffffffffffffffffffffffffffffffff#ec
gdb -> Ack
Recv: "$Z0,a0,2#a5"
Ack -> gdb
###############################################
Try to set a software breakpoint
at address :160 with len 2
Sent: $OK#9a
gdb -> Ack
Recv: "$c#63" 
Ack -> gdb
Sent: $T0520:02;21:5902;22:a0000000;#24            
******** <<< here we have the breakpoint at 160 -> 0xa0
gdb -> Ack
Recv: "$z0,a0,2#c5"
Ack -> gdb
###############################################
Try to set a software breakpoint        
at address :160 with len 2
<<< means unset breakpoint, sorry for the debug output here :-) ->'z'
Sent: $OK#9a
gdb -> Ack
Recv: "$c#63"
<<< That is the problem, gdb do a "continue" but we need a "step"
Ack -> gdb

I have no idea how to fix such things in gdb. But I hope we have some
experts here :-)

As a result from this bug it is not possible to do singlestep if a interrupt
handler is
entered. That is not nice at all.

As a workaround it is possible to add breakpoint after the line where the
irq is raised,
but that is not really what I think is the method to work :-)

I use avr-gdb in version 6.0.
>avr-gdb --version
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=avr".


I also could reproduce the problem with:
GNU gdb 6.1.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=avr".


I hope someone can help us :-)

Thanks
   Klaus