Gnu Debugger for MinGW

[Arnold Trembley]

With a great deal of help from Simon Sobisch, I have built a MinGW-based Gnu Debugger version 13.1 using MSYS2, for installation alongside MinGW GnuCOBOL 3.1.2 or higher, either 32-bit or 64-bit.

The download binary includes the Gnu Debugger manual in PDF format.

https://www.arnoldtrembley.com/GDB-rc0-rename-7z-to-exe.7z

Simply rename the file extension from .7z to .exe and run the file as a self-extracting archive.

This is an early version, so there may be updates to the README and additional documentation, when a new version of the Gnu Debugger is included in MSYS2.

Suggestions for improvement would be greatly appreciated.

Kind regards,

[Mickey White]

I put it in the C:\GnuCOBOL-3.1.2.0 folder. then ran the exe and now readme says I could put in C:\gdb ? Is it ok to be in the 3.1.2.0 folder??

[Mickey White]

It is working, but it is debugging the C program and not showing the cobol syntax ....
later...

[Arnold Trembley]

That's a problem that I ran into as well, but it was the first time I had ever used GDB.

The list command should be able to show you the COBOL source, and I think the TUI (enable, disable, refresh) command can also show you the COBOL source code.

[Mickey White]

Arnold, I have your gnu3.1.2.0 version loaded and previously the MinGW. I think I tried both.... Will look later today. Will your GDB work with the gnu3.1.2.0? I think that is the one I launched and then launched GDB ...
Also does it matter about me putting your GDB in the gnu3.1.2.0 directory?
Never Mind, saw your email.
Thanks both of you !

[Arnold Trembley]

From the email I sent privately:

It should be okay to put GDB in a different location, as long as your path can find the \gdb\bin folder where gdb.exe resides (and the \gdb\lib folder where supporting routines and DLL's reside, etc.). So wherever you install this GDB package, you need to update your PATH to it.

[Simon Sobisch]

If you use cbl-gdb fro COBOLworx (and run the compile wrapper cobcd instead of cobc) you'll only see COBOL code and can cprint (show and set) COBOL variables.

If you compile with cobc -g you have have C debugging with minor COBOL view, if you use cobc -g --debug or cobc -g -fstack-extended -flag-source-location (both of those flags are included with --debug then you get C debugging with many COBOL parts in.

You get into GDB with one of gdb ./prog (when compiled as executable) / gdb --args cobcrun prog / gdb -p <yourpidhere> / gdb --core yourcorefile.
In the last two cases you are likely to land "somewhere" in C, but you can check set a breakpoint to COBOL then use continue.

Core-file debugging does not work on Win32 , but everywhere else. You get a corefile either directly from the system or - especially if runtime checks are active - when telling GnuCOBOL to produce it on aborts with COB_CORE_ON_ERROR=3 (but in that case you can set no breakpoints and would go up/down in the stack instead).

When compiled with one of this approaches you can do all of:

break ELIZA.cob:512        # that's the line number
break ELIZA_:ENTRY_ELIZA
break ELIZA_:SECTION_MAIN
break ELIZA_:PARAGRAPH_MAIN__00_7
break ELIZA_:ENTRY_ELIZA

The key to fast-use GDB is to use its auto-complete via TAB / getting the list of completions with TAB+TAB - in the sample above you'd likely have entered:

br<TAB> EL<TAB>_:PAR<TAB>MA<TAB>

for COBOL you have

• the "main" function, named as the PROGRAM-ID/FUNCTION-ID (case-sensitive), plus an underscore
• entry points with an ENTRY_ prefix (the main entry point is named as the program-id)
  sections with a SECTION_ prefix
• paragraphs with a PARAGRAPH_ prefix and a "magic number" at its end (because you can have multiple paragraphs named identical, even in the same section and I was too lazy to add a check in the codegen if the paragraph only occurs once in the complete program [someone should do that...] to drop that number

stopping at the internal entry point b ELIZA_ will also work if the program was not loaded yet, similar when adding a source reference; using the version with the paragraph/section names and auto-completion in general will only work if the program was either loaded or you add its symbol file manually:

# you may specify a full path here
add-symbol-file testfunc.so
add-symbol-file testfunc.dll

When in COBOL you'll likely use until (executes everything until the next source line) - warning: likely not what you want when the statement is a GO TO / PERFORMor a "go back" from a program/perform - next (that would also "jump" over a subroutine).
If you never want to get into "libcob" then execute skip -rfu cob* and then possibly use a simple step.
If not using cobcd you get a "mixed" debugging, which you see by the switching betweenC and COBOL (but that's not necessarily a "problem"), to show/set variable content you'd then need a function call from GDB with the "C" cob_field (like f_123 - you'd see the one in use in the "C" parts of the mixed debugging).

You can, of course, also execute the program not directly in GDB but use a GDB frontent like VSCodium (for example with the "native debug" extension) or vim's Termdebug or emacs gdb mode.

Note @arn79: you may or may not want to include some of the notes above to the GDB packages README.

[Arnold Trembley]

Yes, I will want to add these notes to the README. Thanks very much!!