COBOL support in GDB

COBOL support in GDB

[Robert Dubner]

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?

 

Thank you very much for your consideration.

 

Bob Dubner

Re: COBOL support in GDB

[Andrew Burgess via 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,
Andrew

RE: COBOL support in GDB

[Robert Dubner]

> -----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

Re: COBOL support in GDB

[Thomas Dineen via Gdb]

COBOL you must be kidding!



On 8/20/2025 5:17 PM, Robert Dubner wrote:
> 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?
>
>   
>
> Thank you very much for your consideration.
>
>   
>
> Bob Dubner
>

Re: COBOL support in GDB

[Guinevere Larsen via Gdb]

Hi.

That is not a very welcoming message to read as the second message Bob 
ever received in this community. If you are just genuinely surprised 
that someone is working with COBOL (or any other technology for that 
matter), I encourage you to be a little more careful with your wording, 
like "wow, I didn't know it was still this important" or "that is very 
surprising, but good luck".

The way your email is worded, it sounds rather dismissive of his efforts 
to add support, which makes the GDB community seem unapproachable.

-- 
Cheers,
Guinevere Larsen
It/she


On 8/27/25 2:42 PM, Thomas Dineen via Gdb wrote:
> COBOL you must be kidding!
>
>
>
> On 8/20/2025 5:17 PM, Robert Dubner wrote:
>> 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?
>>
>>
>> Thank you very much for your consideration.
>>
>>
>> Bob Dubner
>>
>