MIMode "gdb" wrongly assumes the type of Inferior; debugger pause does not work

Okay, here is the scenario. Sorry, long

I am using GDB on my Mac (via MIEngine/cpptools) to debug a program/image running on a board connected to my USB/serial port. Pretty much everything works except for one huge thing. I cannot pause a running target. I can pause it using any other tool (Eclipse, gdb command line, even another VSCode extension, etc.). This is the 99.9% use case for embedded/IoT applications where they can’t actually afford to have an entire OS/gdb running on the board. When I try to pause, nothing happens. I pretty much have to kill the VSCode Debug session, find and kill the gdb-server and/or gdb itself.

I think I know why this is happening. In MICore/src/Debugger.cs, around line 707, you check to see if it is local gdb and assumes program is local too.

Then there is https://sourceware.org/bugzilla/show_bug.cgi?id=20035.

Well, that is only applicable to gdb executing native prorgrams. In our case, gdb is debugging a quasi-remote program in async mode. It is called “remote serial” or “extended remote serial”. The local gdb talks to a gdb-server either using a serial port, local/remote IP address See -target-select doc.

Problem is that gdb-servers can create fake pids and thread-groups if they have to and gdb hasn’t got a clue they are fake. Since MIEngine monitors and collects these pids, it tries to send a SIGINT to the debuggee which will never work. Might even kill an innocent process on local machine? 😃.

Using the gdb command info target When you debug something with gdb, you can figure out what kind of target it is even though gdb and executable are local…

With gdb running on my Mac and board connected to a USB port, it shows.

Symbols from "/Users/hdm/tmp/cystuff/demo/main_final.elf".
Extended remote serial target in gdb-specific protocol:
Debugging a target over a serial line.
	While running this, GDB does not access memory from...
Local exec file:
	`/Users/hdm/tmp/cystuff/demo/main_final.elf', file type elf32-littlearm.
	Entry point: 0x100802ce
	0x10080000 - 0x100811e4 is .text
        ...

With gdb running a local process on Windows/Cygwin, it will say ‘Native process’

Symbols from "/cygdrive/j/VSCode/adv-cppdbg/test/stdc-threads/bin/main.exe".
Native process:
	Using the running image of child Thread 27012.0x5d9c.
	While running this, GDB does not access memory from...
Local exec file:
	`/cygdrive/j/VSCode/adv-cppdbg/test/stdc-threads/bin/main.exe', file type pei-x86-64.
	Entry point: 0x100401000
	0x0000000100401000 - 0x0000000100403040 is .text

Applies to ALL platforms but just for gdb. If you don’t see ‘Native process’, you are debugging something not local. And ‘-exec interrupt’ will work. I have proof. Signaling the Inferior obviously wont work. Unfortunately, I don’t have a MI equivalent of info target. I just did -exec info target You send an -exec-interrupt, gdb says, since I am running remote mode, I will pass it on to the gdb-server and they all report back to MIEngine/VSCode/User

You want to figure out the target type at the start of the session. There is another way, which is to look at the startup commands. Anyone who is doing this will have to execute ‘-target-select’ command during startup, but there are 2-3 ways of doing it syntax wise. Logic for IsLocalGdb() and IsRemoteGdb() has to be reviewed and how they are used. May need isLocalGdbRemoteTarget() for instance. Lucky, these are internal/private all contained in that same file.

Let me know if you want my help fixing/testing this. I apologize, if I misread the code in MIEngine.

[fbs2016]

I meet similar issue on latest extension https://github.com/microsoft/vscode-cpptools/issues/7719 Unable to set breakpoint or pause on a running application with extended-remote connection debug. @haneefdm Could you share the following operation? Thanks I know the workaround is to Control-C in the shell window. It only requires about 4 lines in the launch.json file,

[haneefdm]

Cool. Thanks.