command line gdb debugging symbols/stack trace

Question

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 · Accepted Answer

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.