CBL-GDB Debugging

[Rich Di Iulio]

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:

                -v                       
              -Wall                     
              -Wno-unfinished           
              -Wconstant-expression     
              -frelax-syntax            
              -std=rm                   
              -DOPSYS=$(OSTYPE)         
              -I $(COBCPY)              
              -L $(COB_LIB)

Any help will be very much appreciated!

Rich Di Iulio

[Simon Sobisch]

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])

[Rich Di Iulio]

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

[Simon Sobisch]

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).

[Rich Di Iulio]

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

[Simon Sobisch]

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.

[Rich Di Iulio]

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

[Simon Sobisch]

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".

And if you use that: possibly request that display on hover works...

[Rich Di Iulio]

Well okay, I am stupid, here is an example of my launch.json. Obviously, I am missing something!

        {
            "name": "cobc build and debug",
            "type": "cbl-gdb",
            "request": "launch",
            "linux": {
                "autorun": "/usr/bin/",
            },
            "windows": {
                "autorun": "c:\\GC\\GC312-M64\\BIN"
            },
            "preLaunchTask": "Cross Platform GnuCOBOL Build",
            "program": "${workspaceFolder}/rjd/${fileBasenameNoExtension}",
            "cwd": "${workspaceFolder}/rjd",
            "arguments": ""
        }

Any insights will be very much appreciated.

Rich Di Iulio

[Simon Sobisch]

That's just guessing but maybe it is enough...

    "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.

[Rich Di Iulio]

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

[Rich Di Iulio]

Okay, after looking through the internet for help. I finally got somewhere. I created a .gdbinit file that contains:

add-auto-load-safe-path r:\salonsavvy\rjd\.gdbinit-win

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

[Simon Sobisch]

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

[Rich Di Iulio]

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.

warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /home/rdiiulio/shr/prj/salonsavvy/rjd/SALONSAVVY.
Use `info auto-load 
python-scripts [REGEXP]' to list them.

Hopefully someone can help.

Rich Di Iulio

[Simon Sobisch]

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.

[Simon Sobisch]

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

[Simon Sobisch]

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]).

[Rich Di Iulio]

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:

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

[Simon Sobisch]

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).

[Rich Di Iulio]

Simon,

You speak of Win32, I am running 64-bit environment for GnuCOBOL (mingw64).

[Simon Sobisch]

That's win32 x64 ;-)

[Rich Di Iulio]

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.

I will put the tasks.jsonand launch.json here.

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "Cross Platform GnuCOBOL Build",
            "type": "shell",
            "command": "${workspaceFolder}/tools/tcbld DEBUG",
            "presentation": {
                "echo": true,
                "reveal": "always",
                "focus": true,
                "showReuseMessage": false,
                "clear": true
            },
            "problemMatcher": "$gnucobol-cobc",
            "group": {
                "kind": "build",
                "isDefault": true
            }
        }
    ],
}

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [

        {
            "name": "cobc build and debug",
            "type": "cbl-gdb",
            "request": "launch",
            "preLaunchTask": "Cross Platform GnuCOBOL Build",
            "linux": {
                "autorun": [
                    "source /home/rdiiulio/gc/gc312/bin/cobcd.py"
                ]
            },
            "windows": {
                "autorun": [
                    "source c:\\gc\\gc312\\bin\\cobcd.py"
                ]
            },
            "program": "${workspaceFolder}/rjd/${fileBasenameNoExtension}",
            "cwd": "${workspaceFolder}/rjd",
            "arguments": ""
        }
    ]
}

[Simon Sobisch]

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).

[Rich Di Iulio]

Simon,

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

[Simon Sobisch]

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.