Re: libiberty: Would it be reasonable to add support for GnuCOBOL function name demangling?

[Simon Sobisch <simonsobisch@gnu.org>]

Am 27.05.22 um 20:31 schrieb Eric Gallager:
> On Fri, May 27, 2022 at 3:17 AM Simon Sobisch via Gcc-patches
> <gcc-patches@gcc.gnu.org> 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