target extended-remote with restart support

[DeadRabbits307]

Setup: gdbserver version: 7.11.1 ("gdbserver was configured as "aarch64-buildroot-linux-uclibc"") aarch64-linux-gdb version: 7.11.1 VS Code version: 1.34.0 native debug version: 0.23.1

On the target (embedded Linux OS build with buildroot) I start gdbserveras following: $ gdbserver --multi :2345

My launch.json:

{   
            "type": "gdb",
            "request": "attach",
            "name": "myprogdebug via gdbserver",
            "executable": "./myprog",
            "target": "extended-remote xx.xx.xx.xx:2345",
            "remote": false,
            "cwd": "${workspaceRoot}",
            "valuesFormatting": "parseText",
            "gdbpath": "aarch64-linux-gdb",
            "env": {
                "PATH": "/path/to/cross-compiler:${env:PATH}"
             },
            "printCalls": true,
            "autorun": ["b 27", "set remote exec-file myprog", "run"]
}

With this launch.json debugging with VS code is possible, but without the "restart" and "stop" functionality.
Activating a "Start Debugging" following outputs are produced:

target:

Listening on port 2345
Remote debugging from host xx.xx.xx.207
Process myprog created; pid = 1654
Remote side has terminated connection.  GDBserver will reopen the connection.
Listening on port 2345

host:

1-gdb-set target-async on
2-environment-directory "/home/xy/xy/"
3-target-select extended-remote xx.xx.xx.227:2345
4-file-symbol-file "/some/path/myprog"
5-break-delete
6-interpreter-exec console "b 27"
7-interpreter-exec console "set remote exec-file myprog"
8-interpreter-exec console "run"
9-break-insert -f "/some/path/myprog.c:25"
Breakpoint 1 at 0x400960: file myprog.c, line 27.
Starting program:  
Reading /root/mountp_tmp/myprog from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /root/mountp_tmp/myprog from remote target...
Load new symbol table from "target:/root/mountp_tmp/myprog"? (y or n) [answered Y; input not from terminal]
Reading symbols from target:/root/mountp_tmp/myprog...
done.
thread.c:982: internal-error: is_thread_state: Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? 
(y or n) [answered Y; input not from terminal]

This is a bug, please report it.
  For instructions, see:
<http://www.gnu.org/software/gdb/bugs/>.

Without the "run" autorun-option, following host output is printed:

1-gdb-set target-async on
2-environment-directory "/home/xy/xy/"
3-target-select extended-remote xx.xx.xx.xx:2345
4-file-symbol-file "/some/path/myprog"
5-break-delete
6-interpreter-exec console "b 27"
7-interpreter-exec console "set remote exec-file myprog"
Breakpoint 1 at 0x400960: file myprog.c, line 27.
8-break-insert -f "/some/path/myprog.c:25"
9-exec-continue
-target-detach
10-thread-info
The program is not being run.

On the other hand, running gdb in the terminal (without VS code/native debug) using gdb's command r/restart everything works fine:

target:

$ gdbserver --multi :2345 my_prog
Listening on port 2345
Remote debugging from host xx.xx.xx.207
Process myprog created; pid = 1658
usage: myprog <poll-device>
Process myprog created; pid = 1659

host:

$ aarch64-linux-gdb -q ./my_prog
Reading symbols from ./myprog...done.
(gdb) target extended-remote xx.xx.xx.227:2345
Remote debugging using xx.xx.xx.227:2345
(gdb) set remote exec-file myprog
(gdb) b 25
Breakpoint 1 at 0x400928: file myprog.c, line 25.
(gdb) c
The program is not being run.
(gdb) r
Starting program: /some/path/myprog 
Reading /lib/ld-uClibc.so.0 from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /lib/ld-uClibc.so.0 from remote target...
Reading /lib//libc.so.0 from remote target...

Breakpoint 1, main (argc=1, argv=0x7ffffffc68) at myprog.c:25
25          if (argc < 2) {
(gdb) n
26              fprintf(stderr, "usage: %s <poll-device>\n", argv[0]);
(gdb) n
27              exit(EXIT_FAILURE);
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /some/path/myprog 
Reading /lib/ld-uClibc.so.0 from remote target...
Reading /lib/ld-uClibc.so.0 from remote target...
Reading /lib//libc.so.0 from remote target...

Breakpoint 1, main (argc=1, argv=0x7ffffffc68) at myprog.c:25
25          if (argc < 2) {
(gdb) 

Therefore: Do I have a wrong launch.json file or are modifications to native debug necessary?

[WebFreak001]

can you try to update gdb? The internal problem to GDB seems like it could be a reason (in the mi interface there could be bugs)

[DeadRabbits307]

I tried another setup (without cross compile effort: both x86_64) with a newer version of gdb:

Host: Windows 10 with VS Code 1.36.0 and Native Debug 0.23.1 Terminal: WSL (Arch Linux) with gdb 8.2.1 and architecture x86_64

Target: VMware Player running Manjaro 1800 gdbserver 8.3 architectur x86_64

Here the same: running gdb in the terminal (without VS code/native debug) using gdb's command r/restart everything works fine

Using VS Code following output:

[WebFreak001]

hm I think that's another issue (because /usr/bin/gdb doesn't exist in the scope of the debugger extension, which is its own process)

[DeadRabbits307]

How would the correct gdbpath entry look like?

[WebFreak001]

as you are on windows you need a gdb.exe and point to that with your gdbpath variable (as C:... path)

[DeadRabbits307]

@WebFreak001 you are right.

In the setup of https://github.com/WebFreak001/code-debug/issues/183#issue-464114349 I used aarch64-linux-gdb version 7.11.1

Nearly same setup but with aarch64-linux-gnu-gdb version 8.3 it works; only the autorunentry must be changed to "b main" (entry is important, because otherwise gdb would not stop; breakpoints set by VS code are evaluated/set after(!) the commands listed in autorun).

[GitMensch]

Is it possible to have extended-remote also "directly" (like the remote:true option)? Using the target option like in the first post leads to

Failed to attach: Unrecognized argument "-p" (from file-symbol-file "-p")

GDB -> App: {"outOfBandRecord":[{"isStream":false,"type":"notify","asyncClass":"thread-group-added","output":[["id","i1"]]}]}
GDB -> App: {"token":1,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[]}}
GDB -> App: {"token":2,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[["source-path","X:\\my\\src;$cdir;$cwd"]]}}
GDB -> App: {"outOfBandRecord":[{"isStream":false,"type":"notify","asyncClass":"tsv-created","output":[["name","trace_timestamp"],["initial","0"]]}]}
GDB -> App: {"token":3,"outOfBandRecord":[],"resultRecords":{"resultClass":"connected","results":[]}}
GDB -> App: {"token":4,"outOfBandRecord":[],"resultRecords":{"resultClass":"error","results":[["msg","Unrecognized argument \"-p\""]]}}