This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

command line gdb debugging symbols/stack trace

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.)

  • 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
    
Related