Using debugger with JLink Follow
I'm currently having issues with using the CLion debugger with JLinkGDBServer. I when I run the debug I am able to connect to the server and pause and start execution again, however I am unable to set breakpoints in the program.
I'm using a EFM32ZG222F32 board with has a JLink debugger built in.
I set up a GDB configuration for JLink, however when I try and run a build configuration before launch, I get the error "Not a valid Win32 application". If I try and run a configuration that has a CMake file with commands for starting the debugger, the debugger will start in the command line instead of using CLion's debugger and the build will never finish.
If I try and run debug on the build configuration for the project itself, I get the error: "Cannot determine architecture of the target: elf32-littlearm".
Any Ideas on where I may be going wrong?
Please sign in to leave a comment.
I'm not using JLink, and it sounds like you're running CLion in Windows (I'm using Linux), but having recently started debugging an ARM target using CLion, and solving similar problems, a couple of ideas:
1) Be sure to build with symbols (-g family of switches in GCC). Without symbols it can't correlate the object code to the source code, and it will behave as you've described.
2) Be sure to upload the finished executable for the target being debugged to the machine where CLion is running, and point the "Symbol file" in the GDB Remote Debug configuration dialog in CLion to that file. Any time you rebuild, upload again or the code won't match up and the debugger might look like it's working but odd things can happen.
Thanks for the help, you're right I'm using CLion on windows with MinGW as the selected platform.
Am I correct that if compiling with the -g flag the debugging info is stored in the .hex file that is used to program the device? As this is where I am currently pointing debugger in the GBD configuration settings.
After some more testing I managed to get the debugger to reach breakpoints now. The symbol file seemed to be a file with the project name which had no extension. After starting the GDB server and flashing the device with the latest build after starting the server the debugger works. However the debugger will not hit any breakpoints that are set before the while loop in the main function; is this expected behaviour or is there something else I am missing?
>is there something else I am missing?
Yes, there is a GDB incantation for getting it to break at the entry point at startup. In your case, if you're running a bare-metal app, I'm not exactly sure if this will work, but if not I expect there is a variation that does.
On my Linux box, I had to create a .gdbinit file in my home directory and put in some start up commands:
The first line was required because otherwise the break main would be executed before gdb actually attached to the app and would fail.
Keep in mind that if there is C run-time startup code, that will be run before reaching the main() entry point. If you need to catch it before that you will need to find a defined symbol in that code, or perhaps you can tell GDB to do the initial break at a specific address rather than a symbol name.
A small note about a symbol file:
Symbol file is a file separate from the executable itself which contains program’s debugging information. If you have the binary with the DWARF debug info on the target, you don't need to specify anything in the Symbol File field. If you have the stripped ELF on the target, you must have the Symbol File specified in CLion.