RE: COBOL support in GDB

[Robert Dubner <rdubner@symas.com>]

> -----Original Message-----
> From: Andrew Burgess <aburgess@redhat.com>
> Sent: Wednesday, August 27, 2025 11:54
> To: Robert Dubner <rdubner@symas.com>; gdb@sourceware.org
> Cc: mheyman <mheyman@symas.com>; jklowden@cobolworx.com
> Subject: Re: COBOL support in GDB
> 
> Robert Dubner <rdubner@symas.com> writes:
> 
> > My name is Bob Dubner.  I live in upstate New York, in the United
States.
> > I work for the Symas Corporation, which has an interest in COBOL-based
> > systems.  For the last several years I have been working along with my
> > colleagues Marty Herman and Jim Lowden to develop a COBOL front end
for
> > the GCC compiler collection.
> >
> >
> >
> > That front end, with much gratefully received assistance and support
from
> > the GCC community during the incorporation phase, was released back in
> > March as part of GCC-15.1.
> >
> >
> >
> > So, with GCC now able to compile COBOL, a natural next step is the
> > capability of debugging COBOL code.
> >
> >
> >
> > About three years ago, we forked binutils-gdb on
> > https://gitlab.cobolworx.com/COBOLworx/gdb-cobol.  That's where I have
> > been developing support in GDB for the COBOL language as implemented
in
> > GCC's COBOL front end.  I regularly merge the master branch of
> > git://sourceware.org/git/binutils-gdb.git into our fork, most recently
> > today.
> >
> >
> >
> > I have the COBOL-aware debugger actually working.  Somebody who can
> > navigate the multiple gates of
> >
> >
> >
> > 1) Access to an Ubuntu 22 or 24 system,
> >
> > 2) A willingness to download and install the leading-edge COBOL
compiler
> > from https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/packages,
> >
> > 3) A matching willingness to download and install the leading-edge
> > GDB-COBOL debugger from
> > https://gitlab.cobolworx.com/COBOLworx/gdb-cobol/-/packages
> >
> > 4) Actually caring enough about COBOL to go through steps 1 through 3
> >
> >
> >
> > can then use the resulting installed gcobol compiler to compile a
COBOL
> > program and then use gdb-cobol to debug it.  My intent, so far, is
that
> > GDB users will not be surprised by what ordinary GDB commands do when
> > debugging a COBOL program.
> >
> >
> >
> > I am writing here because it is my belief that we can at least start
> > talking about incorporating my cobol_language work into GDB.
> >
> >
> >
> > It involves eight new files in the gdb directory, all named
> > "cobol-<something>".  There are some changes to code elsewhere in the
gdb
> > subdirectory.
> >
> >
> >
> > I anticipate that there will be a fair amount of polite interaction
about
> > some of my changes that will, nonetheless, come from a place of "Why
in
> > the name of all that is holy did you do THAT??!!"
> >
> >
> >
> > The answers to those perfectly valid questions will be rooted in two
> > places.
> >
> >
> >
> > First, COBOL is weird.
> >
> >
> >
> > Second, I didn't know any better.
> >
> >
> >
> > So, I need guidance on how to proceed.  Perhaps I should come up with
a
> > patch that just installs the some of the cobol-xxx files, so that my
work
> > can be evaluated?  I am sure there will be questions, and comments,
and
> > protests that I will have to address.
> >
> >
> >
> > Or what?
> 
> Hi!
> 
> I don't see why anyone would object to having COBOL support added to
> GDB, especially as the COBOL frontend has been added to gcc.  I would
> certainly have no objections.
> 
> I took a (very) quick look at you git repo, and you are correct to think
> there is a bunch of stuff that's going to require some serious thought
> for how to integrate nicely with current GDB.  I'm looking especially at
> the language specific hooks into generic code step/next, breakpoint
> creation, etc.
> 
> I haven't tried to seriously review any of this work, but I think you
> should understand getting some of this merged might require wider
> refactoring in order to try and keep core code relatively clean.  But
> that's just a guess, I could be wrong.
> 
> For getting the code merged, or starting the review process, the first
> step would be making sure there's a copyright assignment in place with
> the FSF.  I guess you have this already for gcc?  But you should make
> sure it also covers GDB, and if not, get the existing agreement
> extended.
> 
> Got getting patches reviewed and merged, I think you need to break the
> work down into the smallest set of changes possible.  Especially where
> you're touching core code.  So, personally, for a new language, I'm less
> bothered about large changes coming in to cobol-*.{c,h} files, as the
> new language is, well, new.
> 
> But if you tried to land all your changes to breakpoint.c, infcmd.c,
> infrun.c, location.c, etc, etc in one patch, I'm for sure going to ask
> that to be broken apart so we can review one problem at a time.
> 
> Also tests.  We love testing in GDB, and I noticed your branch seemed a
> little light on testing, so that'll need fixing for sure.

Thanks for responding, and thanks very much for starting to look into it.

The first thing I am going to have to do is remind myself to sit on my
hands.  I tend to try to work very quickly, and this effort simply won't
go quickly.  Anybody familiar with GDB who might get interested in this
COBOL effort will have a bunch of counter-intuitive things to absorb, and
that'll take time.

Hell, this is COBOL.  "Counter-intuitive" doesn't really describe it.
"Anti-intuitive" might be better.

I do hear you, loud and clear.

When I started to look at my existing GDB changes with an eye towards
figuring out how to incrementally introduce it to the GDB community, I
realized that there is stuff in there that is clumsy, stuff that is
sloppy, and stuff that just plain doesn't work.  So, I am going to spend
the next few days trying to at least fix the stuff that doesn't work
before trying to introduce patches.

I completely agree that the "if( current_language() == language_cobol )"
stuff I've been sprinkling in the core code is unsightly and distracting.
I look forward to having conversations about why I did it, and what might
be done about it.

Testing:  I do have the beginning of Dubner-flavored regression testing;
it's found in gdb/gcobol/UAT.  The immediate challenge there is going to
be the ongoing need for the version of COBOL-enabled GCC to be compatible
with the version of GDB-COBOL.  I am still at a point where to make things
work in GDB-COBOL, I sometimes have to tweak the executable code that is
generated by GCC.  

I do not, however, have anything that is based on the GDB testing model.
(There is a limit to the number of seemingly vertical learning curves I
feel able to take on at any one time.)

The FSF already has on file both a copyright assigment specifically for my
work on GDB, and a release from the Symas Corporation for such work.

Thanks very much.  These messages are exactly what I needed.  You have
advanced me from "What the heck do I do now?" to "Oh, look:  There is
murky path forward."  That's no small thing.

Bob Dubner.



> 
> Thanks,
> Andrew