Debug is broken with GDB 13

[fbouchoux]

Description

Debugging is not working with GDB 13 on Windows (not tested on other plateforms).

Steps to Reproduce

1. Install a fresh Eclipse for C/C++ Embedded developpers, latest version + ARM GCC 12.2 from ARM website.
2. Create a sample project for STM32F4xx, Hello World version, compile it.
3. Create a new Debug configuration, for example GDB SEGGER J-Link Debugging, setup the device type + .elf file, leave the default options.
4. Start debugging.

Expected behaviour: GBD Eclipse client is working like on the previous GDB versions (for example, there is no problem with GDB 10.1.90).

Actual behaviour: Eclipse is stuck on the "Configuring GDB..." step.

arm-none-eabi-gdb is indeed started with the usual command line (--interpreter=mi2 --nx).
the JLinkGDBServer is waiting for a TCP connection.

The gdb traces console shows this:

Nothing more happens. There is no CPU use at all, Eclipse is just waiting here. The GDB client will never connect to the GDB server, the program is not loaded / started.

However, the GDB arm-none-eabi-gdb client is actually working perfectly when using it from the command line.

Versions

Windows 10 20H2
ARM GCC Toolchain 12.2.MPACBTI-Bet1, including GDB 13.0.50

Eclipse 4.25.1.20220908-1200
Eclipse CDT C/C++ Development Tools Core 7.4.200.202205302218 org.eclipse.cdt.core
Eclipse CDT C/C++ Development Tools Core Native Utilities for Windows 6.0.300.202204200013 org.eclipse.cdt.core.win32
Eclipse CDT C/C++ Development Tools Core Native Utilities for Windows (x86_64) 6.0.700.202208222120 org.eclipse.cdt.core.win32.x86_64
Eclipse Embedded CDT Embedded C/C++ Debugging Core Plug-in 2.0.0.202208180721 org.eclipse.embedcdt.debug.core
Eclipse Embedded CDT Embedded C/C++ Debugging GDB Core Plug-in 5.2.0.202208180721 org.eclipse.embedcdt.debug.gdbjtag.core
Eclipse Embedded CDT Embedded C/C++ Debugging GDB UI Plug-in 5.1.1.202208180721 org.eclipse.embedcdt.debug.gdbjtag.ui

[jonahgraham]

Thanks for testing with a pre-release of GDB, it is really helpful to track down these problems before the full release of GDB.

Where did you get your GDB 13 pre-release from? Does the problem also occur with GDB 12.1?

The MI trace you have provided is showing an error in GDB itself, the 3-gdb-show language is not getting a proper response. It should be 3^done,value="auto" but the 3 is missing. Therefore CDT doesn't know that the answer is to 3-gdb-show language. Since GDB is never responding (as far as CDT knows) the launch is hung trying to configure.

Please let me know where you got GDB from, ideally including the commit it was built from, so we can identify how to formulate a bug report to GDB ahead of their release.

[fbouchoux]

It is the "Beta" version 12.2 of the ARM GNU Toolchain: https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads
From what I see, the GDB build is based on commit a01567f4f7fbbc6ce1492b359c762fcf39e71b4b from last April, so it may indeed be outdated and the issue fixed in between.

I tested with GDB 12.1.90, and the issue is not present.

[jonahgraham]

I can reproduce this error on Windows with the download you provided. It is fairly random, but occasionally CDT isn't receiving the sequence number back.

This is either a GDB or CDT bug, not specifically embed-cdt, but I will persist here until we know where this bug properly belongs and can confirm it is resolved.

[jonahgraham]

I can reproduce this outside of CDT (notice the 2 is missing in the second ^done response.

$ cat input
1-list-thread-groups
2-list-thread-groups
3-list-thread-groups

$ cat input  | ./arm-none-eabi-gdb --silent --interpreter=mi2
=thread-group-added,id="i1"
(gdb)
1^done,groups=[{id="i1",type="process"}]
(gdb)
^done,groups=[{id="i1",type="process"}]
(gdb)
3^done,groups=[{id="i1",type="process"}]
(gdb)
&"warning: Exception condition detected on fd 0\n"
&"error detected on stdin\n"

When I run in the console I do see that GDB detects an exception condition (this is where it is detected) - I think that exception is because of EOF on input, but not sure.

Regardless, the error seems to be on the read side, consider this where the 5 is missing. The command is shortened because if the full groups is there then the error is not seen

$ cat input
1234-list-thread-gro
5678-list-thread-gro
9012-list-thread-gro

ditto-win@DITTO-WIN MINGW64 ~/Downloads/arm-gnu-toolchain-12.2.mpacbti-bet1-mingw-w64-i686-arm-none-eabi/bin
$ cat input | ./arm-none-eabi-gdb --silent --interpreter=mi2
=thread-group-added,id="i1"
(gdb)
1234^error,msg="Undefined MI command: list-thread-gro",code="undefined-command"
(gdb)
678^error,msg="Undefined MI command: list-thread-gro",code="undefined-command"
(gdb)
9012^error,msg="Undefined MI command: list-thread-gro",code="undefined-command"
(gdb)
&"warning: Exception condition detected on fd 0\n"
&"error detected on stdin\n"

[jonahgraham]

On some cursory additional testing it looking like LF line endings cause the problems, but CRLF does not.

[jonahgraham]

This sounds a lot like https://bugs.eclipse.org/bugs/show_bug.cgi?id=579687 - that was about Linux, but the workaround may be the same.

cc: @Torbjorn-Svensson FYI

[jonahgraham]

I believe that this issue is indeed fixed in newer GDB as bminor/binutils-gdb@ac16b09 specifically talks about this issue being resolved.

[jonahgraham]

BTW the bug in GDB was introduced and fixed during the GDB 12 dev cycle. The fix is also part of the GDB 12.1 release in commit bminor/binutils-gdb@e312dfb

Somewhat frustratingly, the 12.2.MPACBTI-Bet1 release is built from an older commit of GDB than 11.3.Rel1, even though the latter was released a month earlier.

[jonahgraham]

I submitted https://bugs.linaro.org/show_bug.cgi?id=5899 so that hopefully the Arm folk can build a new toolchain with a better version of GDB.