Add support for arm-none-eabi-gdb 7.10

[eclipse-embed-cdt]

Add support for arm-none-eabi-gdb 7.10

[ilg-ul]

I'll investigate, but the debugging plug-ins were not yet updated to gdb 7.10.

[ilg-ul]

a few weeks ago the arm-none-eabi-gdb was updated to version 7.10-2

where did you get this version?

the latest version I could find (in GCC ARM Embedded 4.9-2015-q2-update) was 7.8.

./arm-none-eabi-gdb -version
GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs

[0mhu]

I got the version from the Arch repositories:
https://www.archlinux.org/packages/community/x86_64/arm-none-eabi-gdb/

arm-none-eabi-gdb -version
GNU gdb (GDB) 7.10

[ilg-ul]

Arch repositories: ...

ah, ok, so it is not an official release yet.

can you try a debug session with the latest version of the GDB Hardware Debugging plug-in, from the standard Eclipse distribution?

if it is supported and works properly, it'll be easier to update my plug-ins. if not, we'll have to wait for official support in Eclipse.

[0mhu]

It is not possible. Even with the generic one it fails.
Also tested openOCD. Same problem

[ilg-ul]

then I'm afraid it'll take a while to be fixed, my plug-ins are build on top of GDB Hardware Debugging, and mainly handle configuration and starting/monitoring/terminating the server processes, avoiding changing the core classes, since this usually increases later maintenance efforts.

[0mhu]

the problem seems to be in the exec-run command

As far as I could investigate not "run" but "continue" should be used.
However, I don't know the details of GDB. Not sure if that's any help

[Salzi]

I can confirm this problem. If I start openocd in an external terminal and start the gdb manually it works.

arm-none-eabi-gdb my.elf
tar ext :3333
monitor reset halt
load
monitor reset init
thbreak main
continue

It seams that the problem is the run command instead of continue.
Just downgraded (via aur) to an older GDB version and will try that now...

Edit: @Railcrafti Try arm-none-eabi-gdb-linaro from AUR (https://aur.archlinux.org/packages/arm-none-eabi-gdb-linaro).
It's old but works for me.

[0mhu]

Hi. I manually patched the PKGBUILD file of the official packaged back to the version before. It works.
This is the current PKGBUILD:
https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/arm-none-eabi-gdb

You can patch it back to version 7.9. Just edit the version and remove all the checksum and GPG validations.

[ilg-ul]

if I got it right, what you basically say is that the problem is not in GDB, but in the way it was built in ARCH, you fixed this by changing the optimisation level, and with this change the debug plug-in behaves as expected?

[Salzi]

@ilg-ul No I don't think so. He just downgraded to an older version which works. He downgraded to 7.9 and I downgraded to 7.8. Both versions seems to work.
I think the problem is the execute command which is with version 7.10 -exec-run and with all other versions it is -exec-continue.
I don't know from where this change is coming.

[ilg-ul]

Ah, ok, that's not good :-(

I checked the latest GDB source code and both -exec-continue and -exec-run seem to be present.

I also checked a debug session with the current 7.8 and did not find any -exec-run commands.

Could you try to run an identical debug session (via the plug-ins), both with 7.8 and 7.10, and pass me the output of the gdb trace console?

[Salzi]

@ilg-ul I'm happy to provide you with more informations.
Please have a look at this.
There you can see the exec-run command only in the 7.10 file.

[ilg-ul]

there are way too many differences, in my opinion the two logs originate from different configurations.

please redo, using exactly the same debug configuration (preferably j-link), the only change being in the environment to execute different gdb versions.

[Salzi]

I see the point that there are many differences but I haven't change anything.
What I did:

• Start openocd session in an external terminal
• Start debug session in eclipse (gdb 7.8 installed) using the external openocd session
• Copy gdb trace output
• Stop debug session in eclipse
• Remove gdb 7.8 and install 7.10
• Start a new debug session in eclipse using the same external openocd session
• Copy gdb trace output

Both had the same debug configuration in eclipse. I did not even restart eclipse between the two debug sessions and as I already said the openocd session was always the same.
I don't know what I could do to have less differences. Please let me know if you have a suggestion.

Just an other remark: After starting a debug session with the gdb 7.10 version it shows the error and after that I'm unable to restart a new debug session because it tells me that there is already a debug session running. It's impossible to terminate this session. The only thing that helps is restarting eclipse.

[ilg-ul]

perhaps restarting openocd and eclipse before each test will help.

[Salzi]

So next try
I removed the first 6 numbers to better compare the two versions. The version 7.8 has still much more output...

What I did this time

• restart eclipse
• clean project and build it
• start new openocd in terminal
• start new debug session in eclipse with gdb 7.8
• copy gdb trace output
• close eclipse
• close openocd
• turn off and on again target device
• remove gdb 7.8 and install 7.10
• start new openocd in terminal
• start eclipse
• rebuild project
• start new debug session in eclipse
• copy gdb output

[ilg-ul]

there is something in gdb 7.10 that completely confuses Eclipse, and it takes a totally different route, skipping the elf load step; without elf, probably -exec-run is right, it does not know what to do.

time permitting, I'll further investigate.

[Salzi]

Did a little bit of research and found this
So eclipse things that gdb 7.10 is < 7.2 and disabling a lot.

[ilg-ul]

ah, that explains it.

could you try again with Mars 1?

[Salzi]

just updated everything and it still doesn't work :-(
still no download and the -exec-run command

[ilg-ul]

in my plug-ins I had to patch many classes, and sometimes the original classes were not public, so required to duplicate the code, thus preventing them benefit from such updates.

but there are good chances the original gdb hardware debugging plug-in to work. can you confirm this?

[Salzi]

Sorry I'm currently unable to test the original gdb hardware debugger

[lrodorigo]

Hi, I'm currently experiencing same issue, on Arch Linux with GDB 7.10.
I'm using ST-LINK v2.1.

Rolling back to Linaro GDB 7.8 solves for me both on Luna and Mars.1.

This post was really useful, thanks.

[ilg-ul]

I plan to fix the problem in the next major release of GNU ARM Eclipse, due by the end of the year.

For the moment please use GDB 7.8.

[ilg-ul]

I fixed the comparison code in my plug-ins, but with the existing CDT it still does not work, the CDT repository shows that the comparison code was only recently fixed in CDT, so I guess only the next release will be ok.

[scalpel4k]

Hi,
here I'm running CDT master and also a current snapshot of gdb together with a jlink debugger, and everything's working nicely (apart from flash breakpoints).

The CDT change was in september last year and it's part of CDT 8.8 released half a year ago:
https://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=6272b4e523c97678ef29afd8747ba4bdb8f44338

[ilg-ul]

I did not check again the new gdb 7.10, but I confirm that the mentioned patch was indeed included in CDT 8.8, so it should work with Mars 1.

I seem to be having the same problem as the original poster ("Failed to execute MI command:") while trying to get OpenOCD to work with a CC3200 launchpad.

I'm running Eclipse Mars 2 in Windows 7 with all the latest (non-dev) builds and have followed all the steps at gnuarmeclipse.

I know I'm close, because I can connect and debug the target just fine using the command prompt.
Also, the openocd console within Eclipse complains about "JTAG-DP STICKY ERROR"

Any ideas?

[ilg-ul]

I'm running j-link with arm-none-eabi-gdb 7.10 on Mars 2 without problems, so gdb and eclipse are now fine.

if there is any problem, I guess it is in the openocd scripts, which are totally out of my control.

I suggest you check this by trying to connect to another board, preferably a common STM board.

as for the message, MI is not a command, but the protocol used by gdb to talk to the gdb server, so the entire dialog is a sequence of MI commands and mentioning the text "Failed to execute MI command:" is not very helpful.

the other JTAG message "JTAG-DP STICKY ERROR" tells that the JTAG communication failed, probably with the data pin locked, and is also very common when something goes wrong.

are you sure all those many jumpers on the board are set correctly?

Thanks for the reply.

I've got a J-Link on its way, but I'm fearful that the same problem will still be present.

I think the jumpers must be correct because I can get it working via the command prompt.
Based on that, I feel confident that it's something very trivial that I've missed with the Eclipse setup. This is my first time running stock Eclipse so there are many things that I'm recently coming up to speed with.