I’ve successfully been using arm-elf-insight for awhile now, and I’d like to “graduate” to using just console-mode gdb. I’m more familiar with gdb itself and I want to ditch the clutter associated with the insight interface.
What is the appropriate procedure for “running” on the target? I’ve read varying explanations, none of which reliably work for me. As I understand it “running” on a remote target is different than the conventional gdb “run” command for processes that reside in memory on the host machine. What’s the appropriate way for me to kick off/restart my program if I’m debugging a remote (embedded) target. (I’m using the OLIMEX LPC2103 dev board) Here’s where I am so far:
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=arm-elf"...
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
0x7fffe278 in ?? ()
(gdb) load
Loading section .text, size 0xa80 lma 0x40000000
Start address 0x40000050, load size 2688
Transfer rate: 21504 bits/sec, 298 bytes/write.
(gdb) i p
Debugging a target over a serial line.
Program stopped at 0x7fffe278.
It stopped with signal SIGINT, Interrupt.
(gdb)
So what now? I understand I’m not supposed to “run” now, but convince the device to run by other means. I can set the PC to 0x40000000 and kick it off, but that doesn’t work (I expect not, I’m probably at an exception vector, and I don’t change the stack pointer or anything else which is likely full of nonsense) I can reconnect to the target via “target remote localhost:3333” but this only works sometimes, probably for the same reason.
Is there an accepted “clean slate” method? There must be, because insight never misses. What does it do under the covers?