Here's a sample gdb session showing what to do on the gdb
side to get gdb to talk to simulavr:
|
This GDB was configured as "--host=i686-pc-linux-gnu --target=avr".
(gdb) file demo_kr.elf
Reading symbols from demo_kr.elf...done.
(gdb) target remote localhost:1212
Remote debugging using localhost:1212
0x0 in .__start_of_init__ ()
(gdb) load
Loading section .text, size 0x76 lma 0x0
Start address 0x0 , load size 118
Transfer rate: 944 bits in <1 sec, 29 bytes/write.
(gdb) break main
Breakpoint 1 at 0x6e: file demo_kr.c, line 17.
(gdb) continue
Continuing.
Breakpoint 1, main () at demo_kr.c:17
17 sbi(DDRC, (
(gdb) quit
The program is running. Exit anyway? (y or n) y
|
|
Notice that simulavr knew nothing about the program to debug when it
was started. Gdb was told which file to debug with the ‘file’
command. After gdb has read in the program and connected to simulavr,
the program's instructions are downloaded into the simulator via the
‘load’ command. The ‘load’ command is not necessary if
simulavr already has the program loaded into it's flash memory area. It
is ok to issue multiple ‘load’ commands.
Also, notice that no ‘run’ command was given to gdb. Gdb assumes
that the simulator has started and is ready to continue. Giving gdb the
‘run’ command, will cause it to stop the current debug session and
start a new one, which is not likely to be what you want to do.
When specifying the remote target to connect to, it is sufficient to
write “target remote :1212” instead of “target remote localhost:1212”.
Hitting CTRL-c in gdb can be used to interrupt the simulator while it is
processing instructions and return control back to gdb. This is most
useful when gdb is waiting for a response from the simulator and the
program running in the simulator is in an infinite loop.
Issuing a ‘signal SIGxxx’ command from gdb will send the signal to
the simulator via a continue with signal packet. The simulator will
process and interpret the signal, but will not pass it on to the AVR
program running in the simulator since it really makes no sense to do
so. In some circumstances, it may make sense to use the gdb signal
mechanism as a way to initiate some sort of external stimulus to be
passed on to the virtual hardware system of the simulator. Signals from
gdb which are processed have the following meanings:
-
-
SIGHUP
-
Initiate a reset of the simulator. (Simulates a hardware reset).
This document was generated by eweddington on November, 7 2008 using
texi2html 1.78
.