FILE command

[eugeniodilo]

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

[marcsosduma]

In the "resources" directory, we have these examples:

• sample.cbl
• subsample.cbl
• subsubsample.cbl

Execute: cobgdb sample.cbl subsample.cbl subsubsample.cbl

Now it's possible, for instance, to set a breakpoint in "subsubsample.cbl.". Disable the initial breakpoint, type "f," and select "subsubsample.cbl":

Set a breakpoint at line 14:

Type "R" to run the program and "S" to continue debugging.

[eugeniodilo]

Ok Very clear thank you, but now I have a question.

I have two programs that I compile separately like: a. GC01BOX.COB which I compile as GC01BOX.DLL b. GC01BOXDEMO.COB which I compile as GC01BOXDEMO.EXE (both source are at https://sourceforge.net/p/gnucobol/contrib/HEAD/tree/trunk/tools/TUI-TOOLS/)

The GC01BOXDEMO.EXE program executes a call to GC01BOX.DLL. How do I run a GC01BOX debug session?

[marcsosduma]

Hello Prof. Eugenio! In my directory, I copied these files:

cobgdb.exe GC00COLORS.CPY GC01BOX.COB GC01BOX.CPY GC01BOXDEMO.COB GC97KEYCODEGC.CPY GC98KEYCODE.CPY

I was able to run it in two ways:

Method 1:

cobc -m GC01BOX.COB -lpdcurses cobgdb GC01BOXDEMO.COB -lpdcurses

This way, I can debug only the file: GC01BOXDEMO.COB

Method 2:

By passing both programs to cobgdb like this:

cobgdb GC01BOXDEMO.COB GC01BOX.COB -lpdcurses

This way, I can debug both COB files.

[GitMensch]

I think this issue can be closed, as it was a question (at least when the docs are considered to be good, which may not be the case).

The question raised is exactly what #1 is about, and what prevents both this debugger and the "parent vscode extension" to be used in real-world scenarios. Those commonly consists of thousands of programs, generating and linking them at the same time is just not feasible.

Once the generation and the run is correctly split a user can do:

cobc -m GC01BOX.COB -lpdcurses -g  # add more options, if needed, -m is not needed as it is the default
cobcgdb GC02BOX.COB -lpdcurses # wrapper, includes all necessary options
cobcgdb -x GC01BOXDEMO.COB    # this time with -x

# start wrapper for the UI and gdb communication, ideally passing everything
# before the filename to GDB as is
cobgdb GC01BOXDEMO

cobgdb -p $runningprocess

cobgdb (the "run" part) will then start GDB, execute whatever passed and then use GDB to ask for the source (here GC01BOX.c, GC02BOX.c, GC01BOXDEMO.c) and then do its magic.

[eugeniodilo]

I think this issue can be closed, as it was a question (at least when the docs are considered to be good, which may not be the case).

The question raised is exactly what #1 is about, and what prevents both this debugger and the "parent vscode extension" to be used in real-world scenarios. Those commonly consists of thousands of programs, generating and linking them at the same time is just not feasible.

Once the generation and the run is correctly split a user can do:

cobc -m GC01BOX.COB -lpdcurses -g  # add more options, if needed, -m is not needed as it is the default
cobcgdb GC02BOX.COB -lpdcurses # wrapper, includes all necessary options
cobcgdb -x GC01BOXDEMO.COB    # this time with -x

# start wrapper for the UI and gdb communication, ideally passing everything
# before the filename to GDB as is
cobgdb GC01BOXDEMO

cobgdb -p $runningprocess

cobgdb (the "run" part) will then start GDB, execute whatever passed and then use GDB to ask for the source (here GC01BOX.c, GC02BOX.c, GC01BOXDEMO.c) and then do its magic.

sorry but it is not clear what GC02BOX.COB is

[eugeniodilo]

Hello Prof. Eugenio! In my directory, I copied these files:

cobgdb.exe GC00COLORS.CPY GC01BOX.COB GC01BOX.CPY GC01BOXDEMO.COB GC97KEYCODEGC.CPY GC98KEYCODE.CPY

I was able to run it in two ways:

Method 1:

cobc -m GC01BOX.COB -lpdcurses cobgdb GC01BOXDEMO.COB -lpdcurses

This way, I can debug only the file: GC01BOXDEMO.COB

Method 2:

By passing both programs to cobgdb like this:

cobgdb GC01BOXDEMO.COB GC01BOX.COB -lpdcurses

This way, I can debug both COB files.

Ok so you said that currently a subprogram can only be debugged by compiling it together with its calling program. It can work well in many cases.

the issue is the same using the simpler programs you loaded into this project: If I compile them separately: cobc -m subsubsample.cob --> gives subsubsample.dll cobc -m subsample.cob --> gives subsample.dll cobc -x sample.cob --> gives sample.exe

and now I need to debug only subsubsample.cob

[marcsosduma]

Hello ! I didn't get a chance to test it... but I believe this would work: cobc -m subsample.cob cobgdb sample.cob subsubsample.cob

[eugeniodilo]

FILE informations are ok