From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fencepost.gnu.org (fencepost.gnu.org [IPv6:2001:470:142:3::e]) by sourceware.org (Postfix) with ESMTPS id DE4333857B9B for ; Sat, 28 May 2022 07:44:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DE4333857B9B Received: from dynamic-077-013-098-140.77.13.pool.telefonica.de ([77.13.98.140]:38688 helo=[192.168.101.84]) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nur7Q-0004Yv-5y; Sat, 28 May 2022 03:44:16 -0400 Message-ID: Date: Sat, 28 May 2022 09:44:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Content-Language: en-US To: Eric Gallager Cc: gcc-patches References: <54be8f6f-7164-ec40-c327-801e3ba80266@gnu.org> From: Simon Sobisch Subject: Re: libiberty: Would it be reasonable to add support for GnuCOBOL function name demangling? In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2022 07:44:18 -0000 Am 27.05.22 um 20:31 schrieb Eric Gallager: > On Fri, May 27, 2022 at 3:17 AM Simon Sobisch via Gcc-patches > wrote: >> [...] the first question is: is it reasonable to add support for >> GnuCOBOL? >> >> * How would the demangler know it is to be called? Just "best match" >> (GnuCOBOL modules always have some symbols in it which should be >> available if there is any debugging information in, if that helps)? >> * Giving the work of gcc-cobol which was discussed on this mailing list >> some months ago (not sure about its current state) there possibly will >> be a COBOL support be "integrated" - with possibly different name >> mangling. But still - GnuCOBOL is used "in the wild" (for production >> environments) since years (and will be for many years to come, both >> based on GCC and with other compilers) and the name mangling rules did >> not change. > If the plan is to integrate GnuCOBOL into trunk, then I'd say adding > demangling support for it to libiberty would not only be reasonable, > but also a necessary prerequisite for merging the rest of it. Just to ensure that there aren't confusions: Nobody intends to integrate GnuCOBOL [0] into gcc; but it would be important for gcobol for being integrated into gcc to succeed. GnuCOBOL (formerly OpenCOBOL) is a project which translates COBOL to intermediate C (mostly consisting of calls to functions in the GnuCOBOL runtime library libcob), then executes the "native" / system C compiler. It is very mature and used a lot; we _suggest_ to use GCC but also work with other free and nonfree compilers on free and nonfree systems. gcobol [1][2] (I've also seen it referenced as gcc-cobol) is an actual gcc frontend, so translates into gcc intermediate format. As far as I know, the plans are to both provide a usable working COBOL compiler and reach a state for integration until 2023. It possibly will use a very small but important part of libcob (at least if available) to provide support of a COBOL-native way to read/write data. When it comes up to the integration phase it _could_ be considered to integrate only those parts as-is (so effectively forking libcob to glibcob), as both GCC and GnuCOBOL are FSF-Copyrighted - or add it as an optional dependency (a lot of COBOL users don't use that 'old' way of accessing data and moved to EXEC SQL preprocessors instead). But as GnuCOBOL maintainer my question here was about the GnuCOBOL name mangling. I've now learned that as there isn't an explicit prefix like Z_ the de-mangling will be an "upon request", and as far as current responses were it seems like an reasonable approach and "patches to add that are likely to be accepted" (otherwise I won't start, because obviously there is always something to do on the GnuCOBOL side, too). Simon [0]: http://www.gnu.org/software/gnucobol [1]: https://gcc.gnu.org/pipermail/gcc/2022-March/238408.html [2]: https://git.symas.net/cobolworx/gcc-cobol/-/tree/master+cobol/gcc/cobol