marcsosduma / cobgdb Goto Github PK

• Which versions of GnuCOBOL are supported?
• If there's a specific regression on this: which kind of terminals may be used?
• What is the state of this software (maturity, expected release, ...)
• How are contributions handled (I've just assumed "under the license of the repo = GPLv3+, all copyright stays to the original authors).

I think it would be useful to have at the top of the screen on the left side, not only the writing COBGDB but also the version and compilation date .
For example COBGDB v.1.12 050224 to indicate version 1.12 compiled on 05 February 2024.

As noted: really low-priority, but a nice to have:

• hover over variable with the mouse -> show its value after (a possibly configurable) timeout, maybe 1.5 seconds
• support for right click:
  • set/delete breakpoint at selected line (like B)
  • run to selected line (like current C)
  • jump to line (feature missing in general #8)

When you type the Q (Quit) command the debugger send a message where is COBGBD instead of COBGDB.
See image:

during a session of debugging and animating the procedure division code, it would be useful to be able to click on a variable to jump to the working-storage where the variable is defined to see its definition clearly and then be able to return with another click to the instruction in execution to continue with debugging.

for example:

• during the animation ... right click with the mouse on a variable
• a small pop-up window appears with two menu options:
  • displays the content of the variable
  • jumps to the working-storage definition of the variable
• click again with the right button: you return to the animation to continue with debugging ...

I'm trying to download the new version from git but I get an error like there is a virus.

I'm not sure it's a real threat.
Can anyone give an opinion?
Can we find a safe way to download a cobgdb.exe executable?

I have encountered a problem which I will try to describe.

I run cobgdb on program customer.cob
The system displays the first statement with a breakpoint (B) at line 103

I click on Run.
The system execute the Run command = opens a DOS window and places the symbol (>) next to (B) at line 103.

Now I set another breakpoint at any other point.
for example on line 116.

I click on command Step 2 times. All is ok.
I click on command Run to run the program until the next Breakpoint (which would be the new one just inserted at line 116).
The system reopens the DOS window and mistakenly repositions itself on the first Breakpoint al line 103 ?!?!?

you've added some symbols to the top right of the debugger screen (some arrows and others).
I think it would be useful to have a tooltip so that by hovering the mouse over the symbol then the debugger indicates which command is associated with each symbol.

Hello I try to use cobgdb in linux Centos 6.10.

1. I achieve to compile it, by modifying the makefile :
   In the linux part

    LIBS = -lrt
    CFLAGS   = $(INCS) -std=gnu11 -fdiagnostics-color=always -g

2. I tried one of the example :
   ./cobgdb customer.cob

3. I use putty, with xtem emulation
   

4. When I type 'R' to run ;
   

Into the file variables.c at line 883 is specified: "B - Sets a breakpoint at a specific point in the code.",

I think it should be changed to: "B - Sets or Unsets a breakpoint at a specific point in the code.",

Command H or right click displays variable content on screen.
the window disappears automatically after a few seconds

When the variables displayed are quite complex (for example see the attached screenshot) this time is too short, it is not enough to analyze the contents of the variables in the window.
I suggest making the window disappear only with another right click at the user's discretion.
This time could however be configured in a variable to be set in a configuration file called cobgdb.cfg (for example with the same logic as the runtime.cfg file of the GnuCOBOL compiler)

It is not explained and it is not clear to me when and how to use the F = FILE command

Attached user manual new version . Added new -exe option.
Please upload it into GIT repository.

COBGDB-GnuCOBOL-DEBUGGER-V06-20240505.odt

One improvement that would be really useful would be to be able to have a screen size with more than 25 rows x 80 cols when debugging an application.

When we develop using the ">>SOURCE FREE" option instead of ">>SOURCE FIXED" we can write programs with lines of code longer than the fixed format and therefore more readable and therefore better debuggable code.
Having more than 80 columns would make debugging much easier.

Having more lines instead of 25 lines would allow to see a larger portions of the code and therefore a better view of the source.

The better solution would be to be able to choose the screen size of the debug window at the user's discretion.
From a minimum of 25x80 to a maximum of 43x132.

Or we could just have a few options, for example
columns 80 or 100 or 132
lines 25 or 35 or 43

Or even just only two possibilities: either 25x80 or 43x120.

Is this something feasible?

In a cobol program we can have numerical data in different formats: comp, binary, float etc etc
COBGDB currently displays such data in a very strange format.
Apparently, from Simon's indications, it is the "Octal" format.
It would be very useful, if not necessary, to be able to view and edit such data in hexadecimal format.
The following are screenshots of an example program
In some cases I even got an error message "<incomplete sequence ... ?!?!?!

SAMPLE PROGRAM

       >>SOURCE FORMAT IS FREE
IDENTIFICATION DIVISION.
PROGRAM-ID. GCOCTAL.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 random-float   usage   float-long value zero.
01 random-integer pic  99            value zero.
01 random-comp3   pic s99 comp-3     value zero.

PROCEDURE DIVISION.
    perform 3 times
         compute random-float   = FUNCTION random() * 7.0
         display random-float
         compute random-integer = random-float + 1.0
         display random-integer
         compute random-comp3   = random-float - 7
         display random-comp3
    end-perform
    accept omitted
    goback.

When you run a debug session by animating the program, you always start from the first statement of the Procedure Division.
Now the program starts by displaying the debug window from the first line of the code, normally the Identification Division.
To start the session you have to scroll through the entire source for example the working-storage (often many lines of code to scroll through) to select the first instruction after the procedure division, at which point you insert a breakpoint with the command B and then you must execute the R command.
Both of these initial commands (both B and then R) are always repetitive and therefore could be executed automatically every time you start a debugging session.

Request:

• automatic insertion of a breakpoint at the first statement or paragraph of Procedure Division
• automatic execution of the R command
• first screen showed in a debugging session will be the starting point of Procedure division
  next, from this point you can then proceed with the debugging session, for example with the S command.

This behavior could be driven within a configuration file.

Hello

Is there a way for a user to change the screen colors used by Cobgdb?

For example, Cobgdb uses dark blue for some COBOL verbs. I find it hard to read dark blue characters against a black background on my monitor. I would like to change dark blue to light blue.

Thanks

I attach the updated version 03 of the COBGDB user manual.
It would be useful to create a "doc" folder in this git repository and save the document in this folder.
COBGDB-GnuCOBOL-DEBUGGER-V03-20240220.odt

Ideally it would be able to set a condition to a breakpoint after it is reached (you set it at the start, then find that you only want to stop if a variable is > 42).

When you enter into the Change window of a variable,
using the mouse wheel back and forth sets strange characters in the field.
See following sample:

On a clean Ubuntu 22.04:

~ $ sudo apt install -y gnucobol
~ $ mkdir /workspace
~ $ cd /workspace
/workspace $ git glone https://github.com/marcsosduma/cobgdb
/workspace $ cd cobgdb
/workspace/cobgdb (main) $ make
/workspace/cobgdb (main) $ ./cobgdb resources/datatypes.cbl -fixed
Name: resources/datatypes
cobc -g -fsource-location -ftraceall -v -free -O0 -x -fixed resources/datatypes.cbl 
loading standard configuration file 'default.conf'
command line:   cobc -g -fsource-location -ftraceall -v -free -O0 -x -fixed resources/datatypes.cbl 
preprocessing:  resources/datatypes.cbl -> datatypes.i
return status:  0
parsing:        datatypes.i (resources/datatypes.cbl)
resources/datatypes.cbl:45: warning: USAGE BIT is not implemented [-Wpending]
resources/datatypes.cbl:58: warning: handling of USAGE NATIONAL is unfinished; implementation is likely to be changed [-Wunfinished]
resources/datatypes.cbl:59: warning: handling of USAGE NATIONAL is unfinished; implementation is likely to be changed [-Wunfinished]
resources/datatypes.cbl:60: warning: handling of USAGE NATIONAL is unfinished; implementation is likely to be changed [-Wunfinished]
resources/datatypes.cbl:61: warning: handling of USAGE NATIONAL is unfinished; implementation is likely to be changed [-Wunfinished]
resources/datatypes.cbl:62: warning: handling of USAGE NATIONAL is unfinished; implementation is likely to be changed [-Wunfinished]
resources/datatypes.cbl:63: warning: handling of USAGE NATIONAL is unfinished; implementation is likely to be changed [-Wunfinished]
return status:  0
translating:    datatypes.i -> datatypes.c (resources/datatypes.cbl)
executing:      gcc -c -finline-functions -D_FORTIFY_SOURCE=2 -ggdb3 -pipe
                -Wdate-time -D_FORTIFY_SOURCE=2 -Wno-unused -fsigned-char
                -Wno-pointer-sign -ggdb3 -fasynchronous-unwind-tables -O0 -o
                "/tmp/cob1941_0.o" "datatypes.c"
return status:  0
executing:      gcc -Wl,--export-dynamic -o "datatypes" "/tmp/cob1941_0.o"
                -Wl,-Bsymbolic-functions -flto=auto -Wl,-z,relro
                -L/usr/lib/x86_64-linux-gnu -lcob -lm
return status:  0
cobc (GnuCOBOL) 3.1.2.0
Built     Sep 14 2021 19:23:38  Packaged  Dec 23 2020 12:04:58 UTC
C version "11.2.0"
Parser starting...
Parser end...
Unable to open file!: No such file or directory

This is a suggestion to improve the use of the debugger.
I suggest always using open and close square brackets instead of the double quote/apostrophe to delimit the values of the variables in the various windows as the following one.
This is because the double apostrophe is a character that is part of the Cobol characters set and therefore could be contained in a variable.
Other text-based COBOL debuggers (e.g. Microfocus) also use square brackets as containers for these cases.

DESCRIPTION OF THE PROBLEM.

STEP 1. In the following screen, I type the command V (variables)

STEP 2. I get the following screen.
I open the WS-MODULE variable and get its fields.
I go with cursor on WS-OP filed and type the "C" Change command

STEP 3. COBGDB displays the following pop-up with the field already changed and filled whit spaces

STEP 4. At this point, if I exit without doing anything, I will have the variable fixed with all spaces !
See following screenshot.

SOLUTION
Once the pop-up window has been displayed (see previous STEP 3) with variable filled with all spaces, it is currently no longer possible to exit without modifying the variable.

As a solution I would suggest doing the following.

a. display the variable content in the pop-up (see STEP 3) not already at all spaces but with its current value.

b. If I want to modify the variable then I modify (overwrite) it and press ENTER. (this would also allow to modify just a part of the variable - even just one character - without having to rewrite it all)

c if I change my mind and exit without doing anything (please also enable the ESC key which is now not active in the pop-up) or even if I just press ENTER then the value of the variable remains unchanged.

Hi,
just to ask if it is possible for the .exe executable or the executables for windows to be added to this site.
I would like to start using and testing the debugger but avoiding all the work of installing the various components necessary before being able to compile the source code.

Can you explain how variables that are not of type "DISPLAY" should be read and updated from the user.
For example, fields for which a value is displayed with a slash.
In the following sample sScreenName is the variable, it contains a namefile followed by x'00'.
What does \000 means ... or in other cases \262 etc ...

other sample

Sometimes it is necessary to debug some parts of a complex program by skipping the initial parts of the same program.
In these cases, for each repeated debugging session, a breakpoint must be set and re-set to skip the parts of the program that are not of interest and this process must be repeated every time, even many times.
It would be useful to be able to set a breakpoint (or more than one breakpoint) and save them so that they remains stored and settled without having to set it each time you repeat and run a new debugging session.
It could be a "D" command = Debug Save Breakpoints that creates a programname.txt file that contains the breakpoints informations . This file (if it exists) is read and used at each new execution of the debug session to reset all saved breakpoints.

That would for example allow a gdb "knowable" user to do something like break faraway.cob:1335 or to skip WORKINGPROG

We already have "run to selected line" (C), which is often useful.

Especially if you recognized that there was an issue with a condition and want to jump into (or out of) its statenents, or when you want to do a missed CALL again (for example because you've used "N"ext instead of "S"tep an additional "J"ump to is very useful.

if you type the S command twice too quickly the debugger freezes and remains frozen.

see attached screen.

I managed to start a debug session.
the command I used is the following
cobgdb customer.cob -x -Tlista.txt
The system compiles the program and immediately starts the debugging session. See first attached screenshot.
Unfortunately the Step command doesn't work (it does nothing).
Only the V command which displays a list of some variables works (partially).

Starting from the second execution of the command:
cobgdb customer.cob -x -Tlista.txt
I get the error of the second screenshot.
At this point I can no longer run the debugger.

The debug / animator session currently automatically creates a BREAKPOINT at the first PROCEDURE DIVISION statement.
If the program has DECLARATIVES (which must necessarily be positioned at the beginning of the PROCEDURE DIVISION) then the automatic BREAKPOINT is positioned at the first statement after the DECLARATIVES which is not the first statement that will be executed by the program. See a sample at following figure.

In cases like this the automatic BREAKPOINT should be set to the first statement after the END DECLARATIVES.
This is in fact the first statement that will be executed by the program. See following figure.

If it can be useful for testing, I attach the GnuCOBOL source program with DECLARATIVES (it is a program that allows you to manage a simple master file).
Select 01 ADD function at first use will activate the DECLARATIVES to create the master file.

MASTER.COB.TXT

The easiest implementation just works for simple PIC 9 / PIC X, and/or has no validation of the data. A more complex one could do the validation and adjusting as needed (the "upstream" extension should have code in for that).

The E command would be also useful to be handled within the current Variable displays (just popping up as another window).

Depends on #1.

Once this is implemented it would be easy to allow cobgdb 21321 (attach to pid) or cobgdb server:port (attach to gdbserver using extended-remote).

if you find the need to do some pre-processing directly then have a cobcgdb wrapper (that would do cobc -g with every switch you find necessary - but a user may execute the same commands manually) and a cobgdb which is only the frontend

This has the benefit of allowing a connection to a running process/server later - and most important: people can compile now and debug 6 days later (or a real world application consisting of 500+ COBOL modules) without any problem. This is the biggest regression in gnucobol-debug which effectively prevents its use for those type of applications. Please don't copy that regression here.

If data is invalid, then this may automatically be used (like x'202A20' in a COMP-3 field), but in any case it would be nice to be able to view (and after #5 is available also edit) in hex.