command line gdb debugging symbols/stack trace

[Eliot Stock]

Using the pure-gcc makefiles, at present I only see this for a stack trace in the command line gdb client:

(gdb) bt
#0  0xfffffffe in ?? ()
#1  <signal handler called>
#2  0x00000000 in ?? ()

This is weird because I do have symbols:

(gdb) info break
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x00017512 in main at ../main.c:100
2       breakpoint     keep y   0x00016c92 in gsm_uart_connect at ../gsm_ublox_sara.c:239

I'm using -ggdb in my CLFAGS:

CFLAGS += -DDEBUG -ggdb -O0

but have also tried with -g3:

CFLAGS += -DDEBUG -g3 -O0

I start the gdb server with:

JLinkGDBServer -if swd -device nrf51822 -speed 1000 -port 2331

and the client with:

/Users/Eliot/dev/gcc-arm-none-eabi-4_8-2013q4/bin/arm-none-eabi-gdb _build/device-nordic_s110.elf

My .gdbinit is just the one generated by the makefiles:

target remote localhost:2331
break main

(As an aside, it would be helpful to have a value for TERMINAL in the Makefiles for Mac so that I can simply run 'make startdebug', but I haven't been able to find one that works.)

[Ole Morten]

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.

[Eliot Stock]

Much better, thank you!

[asifhn]

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.

[Eliot Stock]

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.

[asifhn]

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.