Re: COBOL support in GDB

Robert Dubner <[email protected]> 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