3

I read through GDB Monitor commands in CLion providing good insight, but I am having a slightly different issue:

My environment:

  • Target: ARM Cortex M4 (STM32F401RE)
  • ST-UTIL gdb server (https://github.com/texane/stlink)
  • arm-none-eabi-gdb 7.7.1+dfsg-5+8~bpo8+1
  • CLion 2016.3.2 Build #CL-163.10154.43
  • Debian 8

In the GDB Remote Debug config panel, I've set:

GDB:         /usr/bin/arm-none-eabi-gdb
Symbol file: /home/malachi/temp/mbed_test/mbed-os-program/BUILD/NUCLEO_F401RE/GCC_ARM/mbed-os-program.elf

From CLion, no matter what I do, I consistently get this for Console:

Cannot configure GDB defaults: No symbol table is loaded.  Use the "file" command.
Debugger connected to localhost:4242

I've tried brute forcing 'file' with a .gdbinit but gdbinit seems ignored

Furthermore, it does indicate a connection to st-util running remotely, but I am unable to execute any commands (breakpoints, stepping, pause, etc) except for terminate - which does seem to terminate it.

If I use arm-none-eabi-gdb direct from command line (/usr/bin/arm-none-eabi-gdb verified), things work as normal, breakpoints, stepping, etc. Also .elf symbols load properly direct from command line.

Lastly, if I use configuration of GDB: Default (Bundled) I don't expect it to work well, but it actually gets further and allows a very limited functionality of pausing/resuming (but with absolutely no other abilities) and does not complain about the symbols

Community
  • 1
  • 1
Malachi
  • 2,260
  • 3
  • 27
  • 40
  • 1
    Have you read [this](http://tom-itx.no-ip.biz:81/~webpage/rue/tutorial.pdf)? Also, you should build your firmware with `-g -fno-omit-frame-pointer -funwind-tables -mapcs -mno-sched-prolog` flags in order to debug your FW with GDB with full functionality. – Sam Protsenko Feb 12 '17 at 12:06
  • Also see [this](http://www.farrellf.com/projects/hardware/2012-06-18_Hardware_Debugging_with_GDB_and_the_STM32F4/). – Sam Protsenko Feb 12 '17 at 12:10
  • Thanks for the insights. No change in the problem, but your info should help stave off future issues. I notice "-mapcs" is deprecated, and oddly - mbed OS debug profile "-fomit-frame-pointer" is explicitly enabled – Malachi Feb 13 '17 at 00:42
  • 1
    In order to investigate it closer we need debug logs. May I ask you to create an issue in https://youtrack.jetbrains.com/issues/CPP and attach the logs as described here: https://intellij-support.jetbrains.com/hc/en-us/articles/206560589-Debugger-doesn-t-stop-on-a-breakpoint-Debugger-shows-Command-timed-out-What-to-do-. Alternatively you send the logs through our support channel: https://intellij-support.jetbrains.com/hc/en-us – Eldar Abusalimov Feb 13 '17 at 10:39

2 Answers2

4

I have a similar setup (except for CLion), and I'm able to debug my STM32 board via STM32F4DISCOVERY (which has ST-LINK v2 on it). Perhaps if you follow my instructions, it will work out for you, too.

First of all, provide next flags to GCC when building your firmware:

# Debug flags
CFLAGS  += -Os -g -fno-schedule-insns -fno-schedule-insns2

# Backtrace support
CFLAGS  += -fno-omit-frame-pointer -funwind-tables
CFLAGS  += -mapcs -mno-sched-prolog
LDFLAGS += -mapcs -mno-sched-prolog

Use next script for starting GDB server. Of course, st-util must be installed, as that script uses it.

#!/bin/sh

CROSS_COMPILE=arm-none-eabi-
GDB=${CROSS_COMPILE}gdb

if [ $# -ne 1 ]; then
    echo "Please provide elf-file for debug symbols" >&2
    exit 1
fi

elf_file="$1"

echo '---> Starting GDB server...'
if [ -f gdb.pid ]; then
    kill -9 $(cat gdb.pid)
    rm -f gdb.pid
fi
st-util & echo $! >gdb.pid

echo '---> Starting GDB...'
$GDB -ex "target extended localhost:4242" $elf_file
kill -9 $(cat gdb.pid)
rm -f gdb.pid

Save it as gdb.sh and run it like this (once you powered up your board):

$ ./gdb.sh your-firmware.elf

You'll see (gdb) prompt. Now you can use usual GDB commands for debugging. In my case, GDB shows me (on start):

GDB connected.

reset_handler () at ../../cm3/vector.c:68
68      for (src = &_data_loadaddr, dest = &_data;

So I'm usually do:

(gdb) break main
(gdb) continue
(gdb) list

And then use usual debugging commands, like step, next, print var, bt, etc. Everything works as expected.

Also it should be mentioned that I'm using libopencm3 in my firmware, so it also might have some influence over success of operation. I'd advice you to build and flash some simple example from libopencm3-examples (like this one), and try to debug it with GDB. If it works, and your code doesn't work with GDB, then you can easily look for difference and find the issue.

References

[1] Debugging details

[2] Using ST-LINK with st-util

Sam Protsenko
  • 14,045
  • 4
  • 59
  • 75
  • Thank you for the thought out response. I've had some success (thankfully) already doing GDB-command-line-only operations, it was mainly CLion environment which didn't seem to be responding well – Malachi Feb 15 '17 at 22:32
0

Upgrading to CLion 2016.3.3 resolves this issue.

I am experiencing some intermittent slowdown/connection issues but I can't be certain that it's a CLion thing.

Thank you Sam Protsenko and Eldar Abusalimov for your help in this.

Malachi
  • 2,260
  • 3
  • 27
  • 40