[Request] "local bootstrap" - Run commands prior to running GDB/LLDB with non-remote options

[Noodlez1232]

Hello!

I'm working on my own OS, and I'm wanting to do some remote debugging using QEMU's built in GDB server. I'd like to be able to run QEMU prior to starting the debugging session. Perhaps there could be added an object called "shell":

An example launch.json configuration:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "gdb",
            "request": "attach",
            "name": "Attach to gdbserver",
            "executable": "kern.x86_64.elf",
            "target": "localhost:1234",
            "remote": true,
            "cwd": "${workspaceRoot}",
            "valuesFormatting": "parseText",
            "shell": {
                "interpreter": "/bin/sh",
                "commands": [
                    "cd ..",
                    "make run&",
                ]
            }
        },
    ]
}

I'm sure this will increase the limited usage of just the remote debugging session, as a majority of people, I'm sure, would like to be able to launch whatever program they want to debug.

[WebFreak001]

you can use vscode's native preLaunchTask & if you have an ssh connection there is bootstrap to run on remote servers

[GitMensch]

I suggest to close this one, the bootstrap for SSH and the prelaunch task (or even both) should already solve that:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "gdb",
            "request": "attach",
            "name": "Attach to gdbserver",
            "preLaunchTask": "make run",
            "executable": "kern.x86_64.elf",
            "target": "localhost:1234",
            "remote": true,
            "cwd": "${workspaceRoot}",
            "valuesFormatting": "parseText"
        },
    ]
}

... and then add a make run task, if it isn't already available (I'd personally suggest to use a single-place .code-workspace instead of the old split json files, but that's only a personal taste issue).

[GitMensch]

Note: I've searched for this today and found that a bootstrap option for non-ssh would be quite useful. Using preLauchTask allows to run arbitrary commands - but I've found no working way to actually set variables the executed scripts (they are executed, then end, so the variables aren't set any more). Explicit setting env BASH_ENV to point to a (single) script which only sets variables "kind of worked", but in the end I had to create a GDB wrapper script which sets the variables, then executes gdb and specify this one in gdbpath - using the exact same scenario but with remote environments, the bootstrap option was enough (using source myscript1 && source myenv2 as its value).

So... reopening with a request to implement that :-)

BTW: actually I'm trying to convert a "network share editing with remote debugging" workspace to a "remote workspace, using remote-'local' debugging" workspace, which kind of works with this workaround...

[renyhp]

What's the status on this?

I'm not sure why preLaunchTask has been suggested, it cannot change the environment of the shell used for debugging. Also, if I'm debugging locally, there is no reason to use the ssh option.

[GitMensch]

The status on this is: no one provided a pull request, so it isn't available "directly". But there is a workaround of writing a minimal wrapper script:

export something=of_value
gdb $*

or

set something=of_value
gdb-multiarch.exe %*

and set the name or path to that script in gdbpath/mipath/...