Re: [Simulavr-devel] gdb-5.1-avr-patch-0.0-pre8 or simulavr Bugreport

[Theodore A. Roth]

I believe it is doing what it should. There is really no way to step over
a tight infinite loop of this type. This is due to gdb, not simulavr. Gdb
will issue the step command until it gets a 'T' packet with the PC of what
it thinks is the next instruction (whatever is _after_ the infinite loop).  
The same thing would happen if you tried to step over a function call that
executes an infinite loop.

For example, compile and run this program natively on linux with gdb:

cat > foo.c <<EOF
int main(void)
{
        while (1);

        return 0;
}
EOF

If you try to step or continue over the while, you can't. Here's the 
gdb dump:

(gdb) b main
Breakpoint 1 at 0x8048433: file foo.c, line 3.
(gdb) r
Starting program: /home/troth/foo 

Breakpoint 1, main () at foo.c:3
3               while (1);
(gdb) s

Program received signal SIGINT, Interrupt.
0x08048434 in main () at foo.c:3
3               while (1);
(gdb) disass
Dump of assembler code for function main:
0x8048430 <main>:       push   %ebp
0x8048431 <main+1>:     mov    %esp,%ebp
0x8048433 <main+3>:     nop    
0x8048434 <main+4>:     jmp    0x8048434 <main+4>
End of assembler dump.

I've tried to match the behaviour of the the native tools. If I didn't, 
I'll have to fix it.

I hope this is a sufficent explanation.

Ted

On Fri, 25 Jan 2002, address@hidden wrote:

:)Yes it works, but I think it doesn't what it sould do.
:)I have entered a step command so I think it should execute one step and then
:)break. 
:)Disassembling of the current PC (after pressing <cntr-c>) shows
:)0x7a <main+36>: nop
:)0x7c <main+38>: rjmp    .-2             ; 0x7c
:)PC is 0x7c (tested with "i reg").
:)
:)gdb sends "$s#73", but simulavr doesn't break after the next instruction. In
:)case of the demo.c program this is the rjump at 0x7c.
:)
:)Reinhard
:)
:)