Debugging

[FrankGun]

Hi,

I am not able to connect to a running gdb process.
Running at Windows 64 bit.
I have running a gdb process in a cmd box.
I start VS Code with gnucobol-debug extension and try to connect to the pid of the gdb process.
The debug console shows only message "getThreads".

Can you please give me any suggestions?

Best regards

Frank

[GitMensch]

That won't work. You don't attach to a gdb process but to either gdbserver (on the console via set target extended-remote, in this case by setting up remoteDebug) or - common on the same machine to a running COBOL process (which you could make to wait by an ACCEPT OMITTED).

Please see https://github.com/OlegKunitsyn/gnucobol-debug#attaching-to-a-running-process for details.

[FrankGun]

now I have added an ACCEPT and run the executable.
But I am still not able to connect to the pid of the process.

[GitMensch]

Please post launch.json and the way you've checked the COBOL PID and a screenshot from vscode, then we're likely able to help more.

[FrankGun]

Windows 7
cobc (GnuCOBOL) 3.1.2.0
C version (MinGW) "10.2.0"
My compile and execute, launch.json and vscode screenshot,
the pid is the same as in the Windows Task Manager

[GitMensch]

Can you attach to the process from cmd?
gdb -p 123456?

What is the output of gdb --version?

[FrankGun]

When I start the gdb from command line I have the gnucobol bin directory in my PATH environment variable.
But how does the vscode extension know where the gdb is?

[GitMensch]

It just uses what is in PATH of vscode. You can test that when opening a terminal in vcode and do the same check there.

But you can setup the path, too in the launch configuration, have a look at gdbpath there.

[GitMensch]

I've rechecked and can reproduce the bad "getThreads" message (again only if explicit "verbose" was activated).
I've found the reason in "there's no cobc in PATH and the extension does not handle that". To get it working set cobcpath in launch.json and be aware that env seems to be either not read at all or not set into environment when cobc is run (so instead you may have to set cobcpath to a wrapper script which sets the environment and then calls it).

The main issue here is that @OlegKunitsyn seems to want to always call cobc. I find that's a reasonable thing to do if the C files (which is needed by this extension to do all the mapping) is not available - but I actually have them all available already and definitely don't want to recompile the application (that's not the task of a debugger) but instead debug it. If it would be on me I'd drop any cobc invocation and both cobcargs and cobcpath and instead have either a "cpath": ["path1", "path2"] configuration or preferable issue a list $current_source.c --> ask GDB to get the source to the plugin, then process that in-memory. For an issue about that (without my preferred new option) see #63.

[FrankGun]

Thanks a million!

I was able to start the debugger. Thats my launch.json:
{
"version": "0.2.0",
"configurations": [
{
"name": "COBOL debugger launch",
"type": "gdb",
"request": "launch",
"cobcargs": ["-x"],
"cobcpath": "c:\gnucobol32\bin\cobc",
"gdbpath": "c:\gnucobol32\bin\gdb",
"cwd":"d:\ibp5",
"target": "d:\ibp5\testcob1.cbl",
},
]
}

I agree with you, it would be nice to have the option to skip the compiler, because the following doesn't work:

1. manually compile my testcob1
2. manually run testcob1, process waits at the ACCEPT
3. in vs code try to attach to pid: generates error at compile because the executable is in use

[GitMensch]

Nice. I think an attach should also work (with for whatever reason a recompilation) when adjusting the launch configuration a bit - @FrankGun please give it a try and report back (and please edit your post above to use a code marker for the json part, easiest would be to add ```jsonc at the start of the block and the same without a language identifier at the end.