Has anyone been able to get CBL-DBG Debugging to work with either Windows or Linux? I am getting an error message: Could not expand variables: undefined command: "cprint"
I was able to get the prebuild command to work and compile the application in debug mode. Is there a cobc switch I am missing? See below:
Second look: that quote seems like you use the cbl-gdb extension for vscode (I personally do not use it because it is currently too much limited compared to GDB+VIM Termdebug which I use, and also much slower). You can use it as soon as you have the setup working (use it on command line first, if it works use the vscode extension in the same environment [instead of passing -x /path/to/cobcd.py in my example below you'd use the "autorun" option with source /path/to/cobcd.py])
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Has anyone been able to get CBL-DBG Debugging to work with either Windows or Linux?
I know several and I've also been able to get it to work myself in Windows (including doing remote-debugging to a Linux-Host running gdbserver using MSYS2 gdb-multiarch.exe) and currently use it quite often under different GNU/Linux environments (mostly CentOS, but also used it in Debian and months ago in Trisquel).
According to its docs you "just" replace cobc by cobcd (all other options stay unchanged) to prepare the modules for debugging (cobc provides source reference and the hints, gcc the DWARF info and cobcd wraps that and adds info for direct COBOL-Variable access).
To then use the debugging extensions with GDB you need "load" the GDB part of cbl-gdb. While there are different ways to do so I highly suggest to just source the extensions on the command line, via a srcipt (if you already use one) or on command line - so for example instead of gdb --args cobcrun prog "some parameter" you'd use gdb -x /path/to/cobcd.py --args cobcrun prog "some parameter".
Note: You need a python enabled version of GDB, but nearly all versions for PC nowadays have that enabled, minimal GDB 7.6, for full features GDB 8.3+ [for my COBOL debugging I currently use GDB 9.2 or 10.2, while for the debugging of GnuCOBOL and sample programs [without cobcd], I mostly use GDB 8.2]).
cobcd.py is the part that provides the cprint and other additional commands (which also can be globally activated by gdbinit, or allowed to be activated with a reference in the .so with an adjustment to the gdbinit file)
Depending on your debugging preferences you may want to have a look at GDB's TUI mode or a frontend like VIM's shipped TermDebug plugin (that's something I currently use often, but VIM was set for code edits before in this project so it was "natural" to use it).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for responding. I am using VS Codium and I had setup my build process to compile using cobcd. That is working just fine. I am running Windows 10 and Linux Mint 20.1. I will try the way you suggest, but will not use VIM (I prefer Emacs).
Rich Di Iulio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sounds good, I'm sure the Emacs bindings for GDB are very well, too, and if needed can be copy+pasted (to then for example call cprint and cwatch if a key is pressed...
First: use with GDB only (possibly in TUI mode if you want to) to ensure everything works.
Then use with Emacs, and then see how well VSCodium integrated debugging works for you compared to that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was able to debug my program from the command line; however, I would like to use the extension for VS Codium. It is complaining that it cannot find cobcd.py. Is there a way to fix this of manually include it after I have pressed <f5>?</f5>
Regards,
Rich Di Iulio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just use the autorun configuration option in launch.json with an entry of source /path/to/cobcd.py and ensure that either cobd-rw is in path or also add the entry "env": "COBCDRW_BINARY=/path/to/cobcd-rw".
"configurations":[{"name":"cobc build and debug","type":"cbl-gdb","request":"launch","linux":{"autorun":["source /usr/bin/cobcd.py"],},"windows":{"autorun":["source c:\\GC\\GC312-M64\\bin\\cobcd.py"],"env":"COBCDRW_BINARY=c:\\GC\\GC312-M64\\bin\\cobcd-rw.exe","gdbpath":"c:\\GC\\GC312-M64\\bin\\gdb-multiarch.exe"},"preLaunchTask":"Cross Platform GnuCOBOL Build","program":"${workspaceFolder}/rjd/${fileBasenameNoExtension}","cwd":"${workspaceFolder}/rjd","arguments":"${input:start arguments}",}],"inputs":[{"id":"start arguments","type":"promptString","description":"Arguments to pass to programm"},]
.. and assuming that your prelaunch task uses make (and within the makefile using cobcd instead of cobc) to not get this stuff compiled over and over again.
Last edit: Simon Sobisch 2021-05-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The launch.json is complaining that the source and env lines have errors (3 to be exact). Yes, I am using a makefile that compiles each of the objects with cobcd. When I run the launch.json, it keeps saying was not able to autoload. I will post the output, a little later tonight. I have to run to a zoom meeting. Thanks
Rich Di Iulio
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Then I created another file called .gdbinit in my development directory and it contained:
source c:\gc\gc312-m64\bin\cobcd.py
Now when I try and run CBL-GDB from VS Codium on Windows 10, I get file not found for gdb-multiarch.exe. I checked my entire hard drive for this and is not found. I had built my GnuCOBOL environment using the document Arnold Tremblay wrote. So today, I downloaded one of his pre-built packages and still no file. Version of gdb is 10.2 in my current environment. The version in the pre-built environment is 7.6.1.
I am now going to work on my Linux laptop (running Linux Mint 20.1) and see how far I can get. I will report back to here with my results.
Rich Di Iulio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Then drop the entry with gdb-multiarch.exe, it comes from MSYS2 (also can debug binaries created by Arnold's MinGW package) and I use it because it can connect to any gdbserver and cross debug GnuCOBOL running on GNU/Linux, too.
You just have to ensure that
gdb --version
outputs a version newer than 7.5, ideally newer than 8.3 and that it is python enabled, which is possibly not the case in the plan MinGW environment... I've previously created a binary package containing the debugger and matching python and will post a link when I'm at the computer (may be some hours until that happens).
Note: If you explicit
source path/to/cobcd.py
In either the autorun or in the gdbinit file, you can drop the auto-load-safe-path.
To see the paths that the .gdbinit files are loaded from see the last lines of
gdb --help
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now I have created the.gdbinit files om Linux, like I did under windows, obviously in the development directory it is .gdbinit-unx. So when I run debug, I am getting the following error in the debug console.
That says it does not find the cobcd.py at the hard-coded path which is inserted by cobcd (I personally disable that feature completely). Execute the command listed in the gdb console to see the path - if you explicit source the cobcd.py you can ignore the warning.
Again, when I'm at the computer will gather and post some more notes for you.
In any case: get it working on the gdb console first.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, checked now, if you export COBCDFMODE=0 (or on Win32 set COBCDFMODE=0) before running cobcd it won't embed any python hint into the executable. [that's what I personally use, or preferably, when building cobcd do make COBCDFMODE=0 and never set the environment var].
Then use one of the following approaches:
manually execute source /full/path/to/cobcd.py in the GDB console (or in the debugging console of vscodium) as first command
let that be done automatically:
in case of using the the cbl-gdb extension for vscode: have an autorun option (my guessed first setup was wrong, I've edited that)
in case of plain gdb command line: pass -x /full/path/to/cobcd.pyas first option to gdb
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As promised: here's a nearly up-to-date binary package for GDB 10 + python for Win32-x64 that can attach to Win32 (both x86 and x64) and GNU/Linux and likely ARM and most other processes: sf-mensch.users.sourceforge.net/files/mingw64-gdb-multiarch.7z That's what I use on Win32 and this also works in vscode (extract somewhere and specify the full path to the binary in the gdbpath option in launch.json [or .code-workspace under launch]).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have updated my windows environment with the update you provided. I am now getting an error message that states missing source code. In the debug console, I enter the following:
source c:\gc\gc312\bin\cobcd.py
At this point, I cannot debug my application.
Now for Linux, it works just fine. I am able to debug my application just fine. So I may have to develop my application under Linux. Then once I gotten to a certain place, just test my application under Windows.
Thank again.
Rich Di Iulio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hm, I'd double check on win32 if you have cobcd-rw.exe either in PATH or (that's my preference) have an environment variable COBCDRW set to its full path (I don't know if my guessing how to do that in the launch configuration above was correct, if in question just set it globally). Note: there's a cobcd-rw.exe in my posted gdb-multiarch package, but that isn't the newest one (I don't know if this is important).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Okay, as I said, I have been able to debug my application under Linux. The cobcd.pyis being invoked under Windows. However, I am getting a error that the source code is missing. It is a weird problem. The network share is not working properly. If I do a dir, I get a complete listing. I have installed GnuWin onto my Windows system. when I do a l, I do not get a complete listing. I get just a few files listed. As I said there seems to be a network issue.
Seeing that I can get this to work under Linux. I am satisfied with what I can do. Thanks to Simon.
Thanks for sharing those. Just a note: I highly suggest to move from different files in .vscode folder to a single .code-workspace file that contain both (benefit beside others: you can also share settings and suggested extensions this way).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for the tips. The tasks.json and launch.json are project specific for use in Linux and Windows. I did move the settings.json contents in the workspace file. However, I still have two workspace files. One for Linux and one for Windows. The settings being in a common area for the platform helps, as I work from two Linux spaces (desktop, vmware).
The idea of having the extensions in a common place for the project would be great. I could not seem to find how.
Again thanks Simon
Rich Di Iulio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure what this means. Why do you have two workspaces (instead of wrapping the parts that are OS specific as you've did in launch.json (or within the called scripts)?
If you give a more detailed layout of your workspace I may be able to give a hint.
While it is not able to put the extension as auto-load in the workspace (you can of course have the vsix files placed within the workspace and install it from there), it is possible to explicit specify in the workspace file which extensions should be active/not active for a given project via extensions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi All,
Has anyone been able to get CBL-DBG Debugging to work with either Windows or Linux? I am getting an error message:
Could not expand variables: undefined command: "cprint"
I was able to get the prebuild command to work and compile the application in debug mode. Is there a cobc switch I am missing? See below:
Any help will be very much appreciated!
Rich Di Iulio
Second look: that quote seems like you use the cbl-gdb extension for vscode (I personally do not use it because it is currently too much limited compared to GDB+VIM Termdebug which I use, and also much slower). You can use it as soon as you have the setup working (use it on command line first, if it works use the vscode extension in the same environment [instead of passing
-x /path/to/cobcd.py
in my example below you'd use the "autorun" option withsource /path/to/cobcd.py
])Sorry, I forgot to add the version number; GnuCOBOL v3.1.2.0, CBL-GDB v4.26.3 and the extension is v4.2.3
Rich Di Iulio
I know several and I've also been able to get it to work myself in Windows (including doing remote-debugging to a Linux-Host running gdbserver using MSYS2 gdb-multiarch.exe) and currently use it quite often under different GNU/Linux environments (mostly CentOS, but also used it in Debian and months ago in Trisquel).
According to its docs you "just" replace
cobc
bycobcd
(all other options stay unchanged) to prepare the modules for debugging (cobc provides source reference and the hints, gcc the DWARF info and cobcd wraps that and adds info for direct COBOL-Variable access).To then use the debugging extensions with GDB you need "load" the GDB part of cbl-gdb. While there are different ways to do so I highly suggest to just source the extensions on the command line, via a srcipt (if you already use one) or on command line - so for example instead of
gdb --args cobcrun prog "some parameter"
you'd usegdb -x /path/to/cobcd.py --args cobcrun prog "some parameter"
.Note: You need a python enabled version of GDB, but nearly all versions for PC nowadays have that enabled, minimal GDB 7.6, for full features GDB 8.3+ [for my COBOL debugging I currently use GDB 9.2 or 10.2, while for the debugging of GnuCOBOL and sample programs [without cobcd], I mostly use GDB 8.2]).
cobcd.py is the part that provides the
cprint
and other additional commands (which also can be globally activated by gdbinit, or allowed to be activated with a reference in the .so with an adjustment to the gdbinit file)Depending on your debugging preferences you may want to have a look at GDB's TUI mode or a frontend like VIM's shipped TermDebug plugin (that's something I currently use often, but VIM was set for code edits before in this project so it was "natural" to use it).
Simon,
Thank you for responding. I am using VS Codium and I had setup my build process to compile using cobcd. That is working just fine. I am running Windows 10 and Linux Mint 20.1. I will try the way you suggest, but will not use VIM (I prefer Emacs).
Rich Di Iulio
Sounds good, I'm sure the Emacs bindings for GDB are very well, too, and if needed can be copy+pasted (to then for example call
cprint
andcwatch
if a key is pressed...First: use with GDB only (possibly in TUI mode if you want to) to ensure everything works.
Then use with Emacs, and then see how well VSCodium integrated debugging works for you compared to that.
I was able to debug my program from the command line; however, I would like to use the extension for VS Codium. It is complaining that it cannot find
cobcd.py
. Is there a way to fix this of manually include it after I have pressed <f5>?</f5>Regards,
Rich Di Iulio
Just use the
autorun
configuration option in launch.json with an entry ofsource /path/to/cobcd.py
and ensure that either cobd-rw is in path or also add the entry"env": "COBCDRW_BINARY=/path/to/cobcd-rw"
.And if you use that: possibly request that display on hover works...
Well okay, I am stupid, here is an example of my launch.json. Obviously, I am missing something!
Any insights will be very much appreciated.
Rich Di Iulio
That's just guessing but maybe it is enough...
.. and assuming that your prelaunch task uses make (and within the makefile using
cobcd
instead ofcobc
) to not get this stuff compiled over and over again.Last edit: Simon Sobisch 2021-05-22
The
launch.json
is complaining that the source and env lines have errors (3 to be exact). Yes, I am using a makefile that compiles each of the objects withcobcd
. When I run thelaunch.json
, it keeps saying was not able to autoload. I will post the output, a little later tonight. I have to run to a zoom meeting. ThanksRich Di Iulio
Okay, after looking through the internet for help. I finally got somewhere. I created a
.gdbinit
file that contains:Then I created another file called .gdbinit in my development directory and it contained:
Now when I try and run CBL-GDB from VS Codium on Windows 10, I get file not found for
gdb-multiarch.exe
. I checked my entire hard drive for this and is not found. I had built my GnuCOBOL environment using the document Arnold Tremblay wrote. So today, I downloaded one of his pre-built packages and still no file. Version of gdb is 10.2 in my current environment. The version in the pre-built environment is 7.6.1.I am now going to work on my Linux laptop (running Linux Mint 20.1) and see how far I can get. I will report back to here with my results.
Rich Di Iulio
Then drop the entry with gdb-multiarch.exe, it comes from MSYS2 (also can debug binaries created by Arnold's MinGW package) and I use it because it can connect to any gdbserver and cross debug GnuCOBOL running on GNU/Linux, too.
You just have to ensure that
outputs a version newer than 7.5, ideally newer than 8.3 and that it is python enabled, which is possibly not the case in the plan MinGW environment... I've previously created a binary package containing the debugger and matching python and will post a link when I'm at the computer (may be some hours until that happens).
Note: If you explicit
In either the autorun or in the gdbinit file, you can drop the auto-load-safe-path.
To see the paths that the .gdbinit files are loaded from see the last lines of
Now I have created the
.gdbinit
files om Linux, like I did under windows, obviously in the development directory it is.gdbinit-unx
. So when I run debug, I am getting the following error in the debug console.Hopefully someone can help.
Rich Di Iulio
That says it does not find the cobcd.py at the hard-coded path which is inserted by cobcd (I personally disable that feature completely). Execute the command listed in the gdb console to see the path - if you explicit source the cobcd.py you can ignore the warning.
Again, when I'm at the computer will gather and post some more notes for you.
In any case: get it working on the gdb console first.
OK, checked now, if you
export COBCDFMODE=0
(or on Win32set COBCDFMODE=0
) before runningcobcd
it won't embed any python hint into the executable. [that's what I personally use, or preferably, when building cobcd domake COBCDFMODE=0
and never set the environment var].Then use one of the following approaches:
source /full/path/to/cobcd.py
in the GDB console (or in the debugging console of vscodium) as first commandautorun
option (my guessed first setup was wrong, I've edited that)-x /full/path/to/cobcd.py
as first option to gdbAs promised: here's a nearly up-to-date binary package for GDB 10 + python for Win32-x64 that can attach to Win32 (both x86 and x64) and GNU/Linux and likely ARM and most other processes: sf-mensch.users.sourceforge.net/files/mingw64-gdb-multiarch.7z That's what I use on Win32 and this also works in vscode (extract somewhere and specify the full path to the binary in the gdbpath option in launch.json [or .code-workspace under launch]).
Simon,
I have updated my windows environment with the update you provided. I am now getting an error message that states missing source code. In the debug console, I enter the following:
At this point, I cannot debug my application.
Now for Linux, it works just fine. I am able to debug my application just fine. So I may have to develop my application under Linux. Then once I gotten to a certain place, just test my application under Windows.
Thank again.
Rich Di Iulio
Hm, I'd double check on win32 if you have
cobcd-rw.exe
either inPATH
or (that's my preference) have an environment variableCOBCDRW
set to its full path (I don't know if my guessing how to do that in the launch configuration above was correct, if in question just set it globally). Note: there's a cobcd-rw.exe in my posted gdb-multiarch package, but that isn't the newest one (I don't know if this is important).Simon,
You speak of Win32, I am running 64-bit environment for GnuCOBOL (mingw64).
That's win32 x64 ;-)
Okay, as I said, I have been able to debug my application under Linux. The cobcd.pyis being invoked under Windows. However, I am getting a error that the source code is missing. It is a weird problem. The network share is not working properly. If I do a
dir
, I get a complete listing. I have installed GnuWin onto my Windows system. when I do al
, I do not get a complete listing. I get just a few files listed. As I said there seems to be a network issue.Seeing that I can get this to work under Linux. I am satisfied with what I can do. Thanks to Simon.
I will put the
tasks.json
andlaunch.json
here.Last edit: Simon Sobisch 2021-05-27
Thanks for sharing those. Just a note: I highly suggest to move from different files in .vscode folder to a single .code-workspace file that contain both (benefit beside others: you can also share settings and suggested extensions this way).
Simon,
Thank you for the tips. The
tasks.json
andlaunch.json
are project specific for use in Linux and Windows. I did move the settings.json contents in the workspace file. However, I still have two workspace files. One for Linux and one for Windows. The settings being in a common area for the platform helps, as I work from two Linux spaces (desktop, vmware).The idea of having the extensions in a common place for the project would be great. I could not seem to find how.
Again thanks Simon
Rich Di Iulio
I'm not sure what this means. Why do you have two workspaces (instead of wrapping the parts that are OS specific as you've did in launch.json (or within the called scripts)?
If you give a more detailed layout of your workspace I may be able to give a hint.
While it is not able to put the extension as auto-load in the workspace (you can of course have the vsix files placed within the workspace and install it from there), it is possible to explicit specify in the workspace file which extensions should be active/not active for a given project via
extensions
.