Menu

gnuCobol debugger for macOS

2025-04-30
2025-06-20
  • David Bourne

    David Bourne - 2025-04-30

    Hi

    I’ve been working my way through a version of COBOL in 21 days. I’ve got to the bonus days talking about debuggers.

    Is there an ‘easy’ way to debug a COBOL program?

    Compiling with the -g or -d flag results in multiple 'ld: warning: -undefined suppress is deprecated’ errors.

    Trying to run the compiled program with gdb reports 'No debugging symbols found in ProgramA’ [as expected].

    Any suggestions? Thanks.

    David

    PS, Thanks for cobc and gnuCOBOL. It has been interesting.
    PPS, to sorry about sending this question in another thread. I thought changing the Subjetc line would create a new thread.

     
    • Mickey White

      Mickey White - 2025-05-01

      Welcome David ! I know very little about macOS but someone will probably help you. If you are debugging a problem , then there are other things you can do. Put display statements through out the program until you get near the statement that is causing a problem. Display fields and variables...
      If you just want to learn gdb then hang around...
      (oh don't worry about the other post, deleted)

       
      • David Bourne

        David Bourne - 2025-05-01

        Mickey, Thanks for the suggestions. I've got most of the way through the book with some small changes. I've been using the display verb to insert debugging output. I need to add some accept dummy lines to be able to see the cascade of output one by one. ;-)
        This approach is also complicated by the use of 'Full-screen I/O' Simple Display doesn't seem to be as useful. I need to re-read that chapter some more.
        Thanks, David

         
        • Anonymous

          Anonymous - 2025-05-01

          Oh, did not know using full screen.
          Do you do a command line to execute ? If so maybe? you can point the display to a file.
          pgm.exe 1>sysout.file 2>syserr.file
          display (defaults to sysout) display to syserr goes to the command line error file..
          Maybe ?

           
          • David Bourne

            David Bourne - 2025-05-01

            A little different with macOS (and probably UNIX).
            Using
            ./MyProgram 1>sysout.txt 2>syserr.txt

            I created both files but no display of the menu on the screen
            sysout.txt contained the screen display
            syserr.txt was empty but may not have caused an error. The program didn't hang as before ;-)
            ./MyProgram 2>syserr.txt

            gave the menu display on the screen but again an empty syserr.txt file. Again, I may not be generating an erro/crash. Might need to try a divide by zero :-)
            Thanks, David

             
            • Simon Sobisch

              Simon Sobisch - 2025-05-02

              Using this debugging technique you'd want to use ACCEPT/DISPLAY "as normal" and use DISPLAY "my debugging output" UPON SYSERR, then redirect syserr only.

              To ensure that you only do this for debugging purposes use the debugging indicator and potentially an environment variable, see https://gnucobol.sourceforge.io/faq/index.html#some-debugging-tricks (just ignoring the "normal" display and add UPON SYSERR for debugging output).

               
    • Vincent (Bryan) Coen

      The LD errors relate to a build / install compiler  step you have missed :

      In /etc  there should be the following folder and files :

      /etc
      /etc/ld.so.conf
      /etc/ld.so.conf.d/
      /etc/ld.so.conf.d/gnucobol.conf
      

      In this last file should be something like -

      /usr/local/lib/gnucobol
      /usr/local/lib
      /usr/lib
      

      For the Mac it might differ slightly but more than likely will be the same and you will have to create this file and content using a TEXT editor

      Having done so now do and assuming you have set up sudo :

      sudo ldconfig

      This will clear the LD error as the Cobol executables cannot find the extra libraries needed for the runtime systems.

      Now for standard debugging which will provide a code trace and a dump if needed, include in the program compiles :

      cobc -x progname.cbl  -d -g -ftraceall -fdump=ALL (may use -m/drop -x as needed)

      Now set for environment using your .bashrc file that sits in your user home folder the following

      # .bashrc
      
      # User specific aliases and functions
      # Source global definitions
      if [ -f /etc/bashrc ]; then
               . /etc/bashrc
      fi
      export COB_SCREEN_ESC=YES
      export COB_SCREEN_EXCEPTIONS=YES
      export COB_LIBRARY_PATH=~/bin
      # next if needed
      export COB_EXIT_WAIT=on
      export TMPDIR=~/tmp
      export DB_HOME=.
      # last one for any ISAM files
      
      export COB_SET_TRACE=1
      export COB_TRACE_FILE=${HOME}/trace.log
      #next if needed or similar
      #export COBCPY=~/cobolsrc/ACAS/copybooks
      
      #  Next as needed
      export PATH=~/bin:.:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/lib64/qt5/bin:/home/vince/bin:/home/vince/.local/bin:/home/vince/mvs380/hercules/linux/64/bin
      

      You will need to exit and then re enter the terminal program for settings to take effect.

      Now when running program you will find in your home folder file trace.log   containing the trace information and a data dump if your program fails with a non recoverable etc, exception.

       

      Last edit: Simon Sobisch 2025-05-02
      • David Bourne

        David Bourne - 2025-05-01

        Hi
        Thanks for the detailed explanation. I'm not sure how I installed gnuCOBOL :-(. It looks like I downloaded gnucobol-3.2 (as the tar.xz file) in Mar 2024 probably from this Source Forge site. While working through the book I had to install a database, i.e. db-berkley. At the time, last month I use homebrew as brew install gnucobol to add db-berkley and jws-jso as dependencies. Before and after the db-berkley install I had v3.2 of gnuCOBOL installed.
        Today after downloading and unpacking gnucobol-3.2.tar.gz I cd to the expanded folder and used ./configure. This time I got an error at the end(?).

        checking for curses mousemask function and mmask_t... yes
        configure: Checks for Berkeley DB ...
        checking db.h usability... yes
        checking db.h presence... yes
        checking for db.h... yes
        configure: error: unable to extract Berkeley DB version information from db.h
        

        BTW my /etc folder doesn't have any ld.* files.

        Sorry, its a bit of a mess but I have been able to compile and run COBOL code with this set-up. Just curious about a debugger.

        Thanks, David

         
        • Benjamin Byrd

          Benjamin Byrd - 2025-06-20

          So you can confirm this with 'cobc --info' , but the brew build of gnucobol is compiled with clang/llvm on mac os.. You should use lldb instead of gdb.

           
          👍
          1
          • David Bourne

            David Bourne - 2025-06-20

            I’m not sure what it is doing but lldb seems to ‘work’ on my Mac M1. I only tried it with hello.cob.;-)

            Benjamin, Thanks. David

            On Jun 20, 2025, at 10:28 AM, Benjamin Byrd bebyrd@users.sourceforge.net wrote:

            So you can confirm this with 'cobc --info' , but the brew build of gnucobol is compiled with clang/llvm on mac os.. You should use lldb instead of gdb.
            gnuCobol debugger for macOS

             
            👍
            2
    • Simon Sobisch

      Simon Sobisch - 2025-05-02

      Is there an ‘easy’ way to debug a COBOL program?

      Sure. You possibly would want to go with cobgdb for the command line option similar to what other COBOL environments provide, or SuperBOL's debugging support if you want to use that within an IDE (vscode based editors, possibly works on Theia as well).

      If you want to go with the full GDB experience (especially if you already know about it or want to write own commands for the debugger / write analysis scripts / use it for automated runs) then cbl-gdb [website is currently restructured, you possibly have to scroll down and get some broken links] is the way to go. This also works well with GDB's TUI mode (always viewing all the COBOL code instead of listing as needed and "in general" with GDB frontends like the VIM or Emacs one). cbl-gdb is what I've worked on as well and rolled out to the COBOL devs for my employer (used daily for development and sometimes for the necessary debugging on the customer side of issues you cannot reproduce locally).

       
    • Simon Sobisch

      Simon Sobisch - 2025-06-06

      Hi David, just to follow-up: how is your COBOL route going and did you got to use one (or more) of the mentioned debugging options?

       
      • Anonymous

        Anonymous - 2025-06-06

        Hi Simon
        Thanks for the follow-up. I'd worked my way through one COBOL back and got distracted with other things. I couldn't get any of the debugging apps wokring. Seemed there were some dependencies that I wasn't able to resolve. The print debugging approach worked for me. My problem was/is with screen writing which complicaged the print/debugging. I was trying to get one of the book examples to work. I probably need to go back to some earlier chapters and/or try a smaller example. Thanks for your previous suggestions.

         

Anonymous
Anonymous

Add attachments
Cancel





Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.