From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id yG0VOqbrtmg1MRIAWB0awg (envelope-from ) for ; Tue, 02 Sep 2025 09:05:42 -0400 Received: by simark.ca (Postfix, from userid 112) id D20511E04C; Tue, 02 Sep 2025 09:05:42 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=no autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id BC61A1E043 for ; Tue, 02 Sep 2025 09:05:41 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4D97E3858C2D for ; Tue, 2 Sep 2025 13:05:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4D97E3858C2D Received: from zmcc-2-mx.zmailcloud.com (zmcc-2-mx.zmailcloud.com [52.37.197.7]) by sourceware.org (Postfix) with ESMTPS id CAEC43858D1E for ; Tue, 2 Sep 2025 13:04:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CAEC43858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=symas.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=symas.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org CAEC43858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=52.37.197.7 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1756818294; cv=none; b=hoZ10qUnzIlo9opzSKZF4V+g/JokZI325O7qXDCbHlsbDiZT+GmK9vlrJwuKq3MT9bnK7c5F5sLZ2WwEOwGGNjWjcNEDpN3uRhSPpptwiAy59HrAQQ1iEBeuyS25lXq5UKEwPa8x0+/26wLefRKTSN7L1HBdcyyR3+gQrWpmJU4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1756818294; c=relaxed/simple; bh=gzQWkUQHTgq5MRKKNwHY6JHNejhNp+z4v0muNY8qzH4=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=ReXCCdMqeJVpin2Ej5Ct2iUINgZ94bANO8Pfw4tqhjmBdgKfEusWdEdI+5tWUAwdZc9HZMHjjD5JJCP5rET/BDAMGcC76glwnFfcEvN0NDQQ6EwS0O6TRKQaNg2Mfyn+a0HeWt93jQuGXbGdJMu/derFGn7T8GhZhNaprx0pS8w= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CAEC43858D1E Received: from zmcc-3.zmailcloud.com (ec2-3-15-255-223.us-east-2.compute.amazonaws.com [3.15.255.223]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by zmcc-2-mx.zmailcloud.com (Postfix) with ESMTPS id 0A026C913DC; Tue, 2 Sep 2025 08:04:54 -0500 (CDT) Received: from zmcc-3.zmailcloud.com (localhost [127.0.0.1]) by zmcc-3-mta-1.zmailcloud.com (Postfix) with ESMTPS id A4842A00E32D; Tue, 2 Sep 2025 08:04:53 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by zmcc-3-mta-1.zmailcloud.com (Postfix) with ESMTP id 8EF7AA00ECCD; Tue, 2 Sep 2025 08:04:53 -0500 (CDT) Received: from zmcc-3.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-3-mta-1.zmailcloud.com [127.0.0.1]) (amavis, port 10026) with ESMTP id WubrNB5c3zrG; Tue, 2 Sep 2025 08:04:53 -0500 (CDT) Received: from zmcc-3-mailbox-1.zmailcloud.com (zmcc-3-mailbox-1.zmailcloud.com [172.31.18.168]) by zmcc-3-mta-1.zmailcloud.com (Postfix) with ESMTP id 29996A00E32D; Tue, 2 Sep 2025 08:04:52 -0500 (CDT) From: Robert Dubner To: "Andrew Burgess" , Cc: "mheyman" , References: <055c01dc1230$fe0c2050$fa2460f0$@symas.com> <878qj469rt.fsf@redhat.com> In-Reply-To: <878qj469rt.fsf@redhat.com> Subject: RE: COBOL support in GDB Thread-Topic: COBOL support in GDB Date: Tue, 2 Sep 2025 08:04:52 -0500 (CDT) Message-ID: <0eff01dc1c0a$2ca05cf0$85e116d0$@symas.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 X-Mailer: Zimbra 9.0.0_GA_4769 (Zimbra-ZCO/9.0.0.1942 (10.0.26100 en-US) Pa6e8 Tc4e8 R14341) Content-Language: en-us Thread-Index: AQJGaynrcjNjEYhiMvEXpEPeYZoCwwJIRzD3s5jzoIA= X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" > -----Original Message----- > From: Andrew Burgess > Sent: Wednesday, August 27, 2025 11:54 > To: Robert Dubner ; gdb@sourceware.org > Cc: mheyman ; jklowden@cobolworx.com > Subject: Re: COBOL support in GDB > > Robert Dubner 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-". 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