Are there any cross platform standalong GDB Gui’s ?

Guys,

I’ve been looking for a way to do in circuit debugging using STLink, which would be an adjunct to the Arduino IDE, but so far I’ve drawn a blank

I can get GDB to work from the command line, but its not a practical solution.

Eclipse have a standalone debugger, but its a pain to setup even on Linux and I’m not sure its supported on WIndows at all

I’ve not tried them, but there is a program called DDD http://www.gnu.org/software/ddd/ which people use to rave about, but it looks like its Linux only (and now seems to be unsupported)

I found a Java based editor called JEdit that has a GDB plugin but its not maintained any more and I just get errors when I try to use the GDB plugin.

I also looked at something called “Beaver Debugger” http://code.google.com/p/beaverdbg/ which is also no longer maintained.
It seems to connect to the ARM GDB, but I’ve not figured out how to send the necessary startup commands.
So its hard to know whether it would be usable or not.

Does anyone else have any suggestions about what could be used.

It would need to be cross platform, and something that could be distributed as part of the repo
I guess having something that could be optionally downloaded would be OK.

Thanks

Roger

DDD looks interesting, here’s another possibility…

https://www.sourceware.org/insight/downloads.php

@ahull

I downloaded insight (latest version) but it gets a compile error in MinGW as all warnings are set to be treated as errors

The last update was in 2009, so unless it works well on Linux, I’m not sure its worth trying to get the windows version to at least compile.

I tried downloading VisualGDB, plugin for Visual Studio (because theoretically Visual Studio 2013 community edition is cross platform)
But didn’t get very far with that with it, because it seems to be targetted at developing and debugging inside Visual Studio rather that just using the debugger on its own.
Either way, it probably not practical for most people to use and its not something I could put in the repo

I’m going to see if I can find out more about how to configure BeaverDebugger, as at least it appears to run and connect to GDB, though at the moment I don’t think its loading the ELF file as none of the windows are showing any source code etc

Just in case its of any use to anyone.

I’ll quickly document how to use STLink and the command line GDB

Currently this is not an automated process, so you’ll need to do some cutting and pasting and have a few CMD windows open in Windows (and shell windows open in Linux)

Set you IDE preferences to verbose for compile and upload
Build and upload your sketch via STLink
Look in the verbose output for the location of the .elf file, for example the path and file will look something like this

C:\Users\rclark\AppData\Local\Temp\build1841586567283255896.tmp/hardware_timer.cpp.elf

Now find out whether the IDE has hidden the C compiler, on Windows in 1.6.3. its in the %appdata%\Arduino15\packages folder e.g.

look at the very first line of the verbose output and you will see it at the start e.g.

C:\Users\rclark\AppData\Roaming\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1/bin/arm-none-eabi-g++

So the path is

C:\Users\rclark\AppData\Roaming\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1\bin\

Now save this path somewhere e.g. a text editor and append the GDB exe

so the whole path to the debugger is

C:\Users\rclark\AppData\Roaming\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1\bin\arm-none-eabi-gdb.exe

Open a command window (or Linux shell)

Then paste this address followed by the full path to the elf file e.g.

C:\Users\rclark\AppData\Roaming\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1\bin\arm-none-eabi-gdb.exe C:\Users\rclark\AppData\Local\Temp\build1841586567283255896.tmp/hardware_timer.cpp.elf

press enter and this will run gdb and tell it to load the ELF file for the sketch (the elf file contains all the information about the file you have uploaded that GDB needs)

Now open another Command prompt and cd to where your tools folder is

You can find the path by looking at the verbose output just before it does the upload

e.g.

C:\Users\rclark\Documents\Arduino\hardware\Arduino_STM32/tools/win/

cd to this folder and then into the texane-stlink folder and run the st-util program

This will output some text about the type of processor you have, but the program should not return to the command prompt as it remains running

Go back to your other command prompt, which is running GDB, and type

tar ext :4242

You should get a message

Remove debugging using :4242

This means its connect to the st-util program you ran in the other command prompt

You can now issue GDB commands

You can look them up, but a good start is to issue a kill command

kill

This will reset the currently running program on your board

if you now type

list

you will see some assembler code, which is the first 10 lines of code that get executed when the program runs.
These are not the first 10 lines in the sketch, the sketch code is called from inside main, and before even main is loaded, a lot of setup code is run, some of which is in assembler

now type

run

and after a few secs your program will start to run

If you press control C while its running, GDB will stop the execution and list the file and line on which it stopped.

I suspect in most sketches this is likely to be a delay, however the code could be anywhere including in things like system interrupts

type

list

to see the code,

press

continue to carry on

There are loads of GDB commands, and plenty of docs on the web

BTW, if you program does something nasty, like attempt to access a memory location, GDB will normally just stop and tell you where it has crashed, but I’m not an expert and I guess it may not be able to do that for all such errors.

Anyway. Although this method of debugging does work, as you can see, its rather hard to use, so the sooner we can get a graphical interface to GDB working, the better.

@Roger:

Did you look over this list:
https://sourceware.org/gdb/wiki/GDB%20Front%20Ends

Ray

Thanks.

The debuggers I’ve been looking at are mostly from that list

The problem seems to be that hardly any of them are standalone.

The ones that are part of an IDE, don’t normally let you start the debugger separately and pass the ELF file to the debugger.

The Arduino IDE seems to be about 5 years behind the times on this front, as it doesn’t interface to GDB .

I have tried one of two of the IDEs in that list, but by the time I download and then install and sometimes have to do post install of plugins etc, and then try to figure out if I can run the debugger separately, it takes quite a while

So at the moment I keep going back to GDB on the command line

I posted to the developers Arduino mailing list about it, as i thought they may have started some work to support in circuit debugging on the Zero, but I don’t think I’ve had any replies

You might want to check out this thread:

http://www.stm32duino.com/viewtopic.php?f=35&t=113#p837

Rick

Thanks

Are you using Eclipse as a standalone debugger using the ELF file from the IDE ?

I thought you were compiling in Eclipse.

I could get Eclipse StandAlone debugger to run up on Linux, but I can’t find any docs about whether it works at all on Windows.

If I get time (unlikely), I was hoping to figure out how the standalone debugger was started up on Linux and attempt to replicate on Windows.
Because the majority of people (I think around 80%) are using Windows.

The other thing, that would need to be worked out, is how to stop st-util running.

On Linux that would be less complicated, as you can just do

./st-util &

to run in the background,

and then use kill to get rid of it

However its not so simple on Windows ;-(

I wonder if GDB can send a message to the st-util server to tell it to quit. That would possibly be one solution.

Or can GDB tell st-util to upload a new binary ???

RogerClark wrote:Are you using Eclipse as a standalone debugger using the ELF file from the IDE ?

Rick.

OK. I just did a couple of tests

Start /B st-util.exe

works and starts in the background

taskkill /F /IM st-util.exe

kills the task

So, just, need to get Eclipse CDT standalone debugger to even run on Windows

I got a reply from an IDE dev team member (Cristian Maglie)

A debugging GUI for the Arduino IDE is planned, but is not going to happen soon.

So we are just going to have to lead the way on this one.

I’m kind of surprised that the Teensy doesn’t do this already, but it looks like the SWD connections need to be soldered on by hand, so hardly any one has ventured into this area.

Just a quick update.

It looks like DDD will possibly run on both Linux and Windows, so may be one way for Windows users to have In Circuit debugging, however I’ve not managed to get DDD to work correctly yet.

On Linux, the best way to install DDD appears to be via apt-get as the currently available source from the DDD project site doesn’t compile.

Andrew Knoll from the IDE developers mailing list is hoping to put his patched version of the DDD source onto GitHub, so there will be a version that compiles for Linux , but he has not done it yet.

On Windows DDD can be installed by installing Cygwin, including the X11 optional files.

Once this is installed you just type DDD from the Cygwin command line and DDD starts in a new window

However the issue at the moment on windows is the paths to the source files.

The .elf file is created as part of the build process by the IDE but the paths to the files are windows style e.g. c:\ and DDD seems to have an issue with this. Not only the flash direction but the C:
This is because Cygwin doesn’t have a path called C: , it maps C to a sub directory inside Cygwin s file structure

At the moment I don’t have a solution for this.

I tried doing a search and replace in the elf file (binary) of back slashes to forward slashes but it doesn’t help because of the C:

And as the elf file is a binary, its not possible to simply replace c: with the Cygwin path to C

GDB has a path substitution feature, which I have not tried yet, which may be able to do the conversion, or there may be a way to either compile without full paths being inserted into the elf file or possibly run some utility on the elf file to do path conversion.

So at the moment DDD looks like it may be usable if I can get over the path hurdle.

On the Eclipse debugger front.
I posted to the Eclipse forum a few days ago, but last time I checked, no one had replied to my question about whether a windows version was available.

So that avenue is on hold at the moment

DDD has the advantage of being possibly a smaller footprint and arguably a lesser learning curve than Eclipse, but I’ll take either (or indeed both ).

RogerClark wrote:This is because Cygwin doesn’t have a path called C: , it maps C to a sub directory inside Cygwin s file structure

Martin

Cygwin seems to map this by default for me, but he elf file generated by the IDE has windows paths

Perhaps I need to try running the IDE from inside Cygwin so it gains Linux style paths.

However that may break the IDE

Edit

I just tried running the IDE from the cygwin shell window. The IDE ran ok (surprisingly), but the paths are still no good.

They still contain the C:\ , even though they use a temp folder under cygwin rather than the windows temp folder

I doubt just doing text replace on the elf file is going to fix the paths, because I suspect the file has an internal structure which I would break by changing the lenghts of these strings. The only hacky workaround would be to do the replace, and copy the files to another path under cygwin that had the same number of characters, i.e so that none of the C strings in the elf file would need to have their length changed.

I will see if the source path substitute working in GDB

set substitute-path C:\Users\rclark\AppData\Local\Temp /cygdrive/c/Users/rclark/AppData/Local/Temp

see
https://sourceware.org/gdb/onlinedocs/g … -Path.html

because they are same directores, but one is the cygwin mapped version and the other is the windows version

Guys,

I got a reply from the Eclipse developers..

Subject: Re: How can I use Eclipse Standalone Debugger for embedded debugging? Author: Marc Khouzam Date: Tue, 19 May 2015 19:21
The current version of the CDT Standalone debugger uses scripts that only work on Linux.
Some documentation here: https://wiki.eclipse.org/CDT/StandaloneDebugger

However, CDT committers are working on a RCP version of the Standalone debugger that should work on Windows.
It should be ready by the next Eclipse/CDT release June 24th, 2015.

This is good news, because although we may be able to get DDD to eventually working on Windows, I think Eclipse is going to be a better solution, as its something which is actively being developed unlike DDD which is effectively no longer supported.

I will liaise with the Eclipse team e.g. Send them a ELF file generated by the Arduino IDE etc, so that we don’t have the same issues with full paths containing back slashes etc

I’m warming to the Eclipse solution, I did manage to get DDD to work today with my “ST-Link V2” clone.

I’ll tidy things up and write a how to on the wiki when I get a chance. It was a little flakey. I’m not sure if that is down to the version of DDD I was using, so it may need a fair bit of polish before it is completely usable.

@ahull

OK about DDD.

I don’t think its going to work on windows because of the full paths in the ELF file, screwing up DDD’s file load

I’m sure if there was no alternative, either we could modify and recompile DDD for windows so that it understood the back slashes etc or write some code to process the elf file, but I suspect that Eclipse is a better option.

I have successfully debugged my STM32F4 using eclipse with Zylin Plugin and OpenOCD-0.8.0 . Zylin has options for Native or Cygwin and is quite easy to set up.
For register view I used Embsysregview which is a really nice plugin for eclipse that brings up ALL the registers on your board. You can change the register values bit by bit ON THE FLY!!!!

theres a good tutorial here:
http://vedder.se/2012/12/debugging-the- … d-eclipse/

Thanks

Mubase.

I noticed that the STM STLink GUI tool appears to allow you to read and set the internal registers, so it looks like bit control of the registers would be possible.

I think this is all standard stuff for ARM processors, and not something that STM themselves has implemented, so there is probably a lot of information about it in the ARM website etc.