command line gdb debugging symbols/stack trace

RE: command line gdb debugging symbols/stack trace

Clem Taylor — Wed, 08 Jul 2015 00:32:26 GMT

Try:

mon reset
load
mon reset
continue

The macro I use:

define rc
   # reset and halt CPU
   mon reset
   printf "Run...\n"
   continue
end 

define lc
   load
   rc   
end

For me 'lc' prints:

Loading section .text, size 0x151f8 lma 0x18000
Loading section .ARM.exidx, size 0x8 lma 0x2d1f8
Loading section .data, size 0xd8 lma 0x2d200
Loading section .fill, size 0xbd24 lma 0x2d2d8
Loading section .appCRC, size 0x4 lma 0x38ffc
Start address 0x6d0, load size 135168
Transfer rate: 13200 KB/sec, 3653 bytes/write.
Resetting target
Run...

I used to use 'load' then 'run', but that requires 'gdb extended-remote' mode and some point in the recent past Segger broke breakpoint support in 'extended-remote' mode.

I really don't trust the Segger stuff, I recently discovered if you load code onto a chip with the memory protection bits set, JLinkGDBServer will happily report:

Downloading 4096 bytes @ address 0x00018000 - Verified OK

RE: command line gdb debugging symbols/stack trace

asifhn — Tue, 07 Jul 2015 22:56:56 GMT

I get the same problem as originally stated. And doing a "load" in gdb after "target remote ..." causes error:

(gdb) load
Loading section .text, size 0xa9d7 lma 0x16000
Loading section .ARM.exidx, size 0x8 lma 0x209d8
Loading section .data, size 0x6c lma 0x209e0
Error finishing flash operation

For whatever reason I cannot continue after I do the gdb "load". I have to re-program the nordic flash to be able to do a gdb continue. Does gdb "load" corrupt the nordic flash? I wonder!

By-the-way, I use openocd as my gdb server. I think this has something to do with sigint, but I am not sure.

RE: command line gdb debugging symbols/stack trace

Eliot Stock — Tue, 07 Jul 2015 22:53:10 GMT

This is not an answer. I'd post it as a new question and link back to this one if you want an answer to it.

RE: command line gdb debugging symbols/stack trace

asifhn — Tue, 07 Jul 2015 22:48:08 GMT

I get the same problem as originally stated. And doing a "load" in gdb after "target remote ..." causes error:

(gdb) load
Loading section .text, size 0xa9d7 lma 0x16000
Loading section .ARM.exidx, size 0x8 lma 0x209d8
Loading section .data, size 0x6c lma 0x209e0
Error finishing flash operation

For whatever reason I cannot continue after I do the gdb "load". I have to re-program the nordic flash to be able to do a gdb continue. Does gdb "load" corrupt the nordic flash? I wonder!

By-the-way, I use openocd as my gdb server. I think this has something to do with sigint, but I am not sure.

RE: command line gdb debugging symbols/stack trace

Eliot Stock — Fri, 28 Mar 2014 14:38:41 GMT

Much better, thank you!

RE: command line gdb debugging symbols/stack trace

Ole Morten — Fri, 28 Mar 2014 14:13:02 GMT

The pure-gcc makefiles by default doesn't currently automatically load the binary and reset the chip, and if the flash contents isn't according to what GDB expects, you'll often see this 0xFFFFFFFE address.

If you always want to do such load before you start debug, you can add the command load and mon reset to the gdbinit like this:


target remote localhost:2331
load
mon reset
break main

I'll consider changing this upstream as well, but the default behavior is useful if you want to connect to a running target... Thinking about it a second time however, the suggestion above is perhaps what's best for the 90 % use case, so it might make sense to change it.