How to use this extension with coredumps [missing in README]?

[GitMensch]

So far I've only started the application, then used the debugging console or autorun to load a core file.
But there is likely a better way, isn't there?

Thinking about that it would be likely useful to have an extra launch type for that which has no pause/run/step active (if this is actually possible with the dap).

Additional:
On systems with installed systemd-coredump all created coredumps are taken into its db and the last one can always be inspected with gdb using coredumpclt debug (you can filter for example with pid or executable name, too).
It would be really nice to start this instead of GDB - but I have no clue if this would work, I guess via its --debuger (default is gdb - we'd just set the gdbpath there) and via --debugger-arguments= (to pass the collected startup commands).
That would be useful both locally and for ssh-remote. Maybe a new type "core" with an optional boolean argument coredumpclt?

[GitMensch]

For the last question with that issue see #121, which gave the better workaround of modifying the debugger arguments to prevent running the executable:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "gdb",
            "request": "launch",
            "name": "load core",
            "target": "a.out",
            "cwd": "${workspaceRoot}",
            "debugger_args": [
                "${workspaceRoot}/a.out", "${workspaceRoot}/core"
            ]
        }
    ]
}

[GitMensch]

As noted in #385 this seems to have been possible years ago, but it isn't any more, because exec-run is always executed.

Current work-around attach to a dummy process (it must exist and you must have debugging rights - most easy by echo | less, then sending that to background and get the pid):

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "gdb",
            "request": "attach",
            "name": "load core",
            "target": "123456",
            "cwd": "${workspaceRoot}",
            "autorun": [
                "detach",
                "file ${workspaceRoot}/a.out",
                "target core ${workspaceRoot}/core"
            ],
            "stopAtConnect": true,
        }
    ]
}

And if you use the coredumpctl binary / service you can use a pre-launch task which will create symlinks you can use instead of the hard-wired single process.

It would be much better to directly support coredumps, for example by checking the target in the attach configuration and if it is a file, execute -target-select core $target (which likely needs executable be set and executed as -file $executable before the target select).

@brownts That sounds like a reasonable plan for the next release, no?

As an alternative we could do the same as the cpptools extension and add a coreDumpPath attribute which is read for the launch configuration, leaving target as the executable - and then directly execute gdb $target $coreDumpPath; ... or make it much easier and don't execute exec-run if debugger_args is specified (as it seem to have been in 2017).

[brownts]

You can also do this by utilizing the "extended-remote" option as well. Have a preLaunchTask start gdbserver (i.e., gdbserver --once --multi :2345) and use the following configuration. This removes the need to have a dummy process available:

{
	"type": "gdb",
	"request": "attach",
	"name": "GDB: Attach Extended Remote (Core File)",
	"executable": "hello_world",
	"target": "extended-remote :2345",
	"stopAtConnect": true,
	"cwd": "${workspaceFolder}",
	"preLaunchTask": "gdbserver:multi-once",
	"autorun": ["file hello_world", "target core core.3359659"]
}

It's still a "hack" on what should be available as straight forward attach. Yes, this does seem reasonable for the next feature release. This is what I had hinted about in #330.

[GitMensch]

How is your prelaunch task defined? The following does not work:

				"label": "gdbserver:multi-once",
				"windows": {
					"command": "C:\\MinGW\\bin\\gdb-multiarch.exe",
				},
				"linux": {
					"command": "gdbserver",
				},
				"args": [
					"--once",
					"--multi", ":2345",
				],
				"isBackground": true,
				"group": "none",
				"problemMatcher": [],
				"presentation": {
					"echo": false,
					"reveal": "never",
					"focus": false,
					"panel": "shared",
					"showReuseMessage": false,
					"clear": false
				}

[brownts]

This is what I'm successfully using on Linux. Which platform are you running this on? Also, is your Windows command running gdb or gdbserver?

        {
            "label": "gdbserver:multi-once",
            "type": "process",
            "command": "gdbserver",
            "args": ["--once", "--multi", ":2345"],
            "isBackground": true,
            "problemMatcher": {
                "pattern": {
                    "regexp": ".",
                    "file": 1,
                    "location": 2,
                    "message": 3
                },
                "background": {
                    "activeOnStart": true,
                    "beginsPattern": ".",
                    "endsPattern": "."
                }
            },
            "group": "test"
        }

[GitMensch]

I see, that's microsoft/vscode#6209, one needs an explicit problem matcher, that's... special.
It still doesn't work for me using this exact same definition, the launch does not start. It does work when manually starting that process, then creating the launch (in this case it is ideal to drop that "once", of course.

Note: I don't see any interaction to show local variables - should there be some? Did I somewhere possibly dropped that with a setting? [note: hovering over variables leads to the data-evaluate-expression call and the returning output is also resolved nicely in the gui - the variable pane "Local" is just empty.

[brownts]

I see, that's microsoft/vscode#6209, one needs an explicit problem matcher, that's... special. It still doesn't work for me using this exact same definition, the launch does not start. It does work when manually starting that process, then creating the launch (in this case it is ideal to drop that "once", of course.

Yeah, getting the matcher correct is a pain, but I remember running across that in the past and had this in my back pocket from some previous launcher I had cobbled together.

Not sure why it's not working for you. With that setup, at least on Linux, I'm not having any problem launching gdbserver.

Note: I don't see any interaction to show local variables - should there be some? Did I somewhere possibly dropped that with a setting? [note: hovering over variables leads to the data-evaluate-expression call and the returning output is also resolved nicely in the gui - the variable pane "Local" is just empty.

Not quite sure exactly what you're seeing, but I do see many local variables shown. I do see that some seem to have problems (which should be investigated), but others are displayed fine. Here are a couple snapshots from my hello_world example. I just ran this and when it's in the sleep loop, I ran "gcore" on it to generate a core file. Then loaded it as previously described.

[brownts]

One question about the local issue you are seeing, I was wondering if you're running with the latest. There was a local variable issue I fixed in #342. If you don't have that fix, then depending on which stack frame you're looking at, you might not see local variables. That wouldn't be specific to the core file, but to the extension in general.

[GitMensch]

I'm using the last release, as most people :-) 0.26.0 - that fix is not included there.