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

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

[Simon Sobisch]

[-- Attachment #1.1.1: Type: text/plain, Size: 1569 bytes --]

Hi fellow hackers,

first of all: I'm not sure if this is the correct mailing list for this 
question, but I did not found a separate one and 
gnu.org/software/libiberty redirects to 
https://gcc.gnu.org/onlinedocs/libiberty.pdf - so I'm here.
If there's a better place for this: please drop a note.

I've never "worked" with libiberty directly but am sure I'm using it 
quite regularly with various tools including GDB and valgrind.
Therefore I currently cannot send a patch for the function name 
demangling, but if this is a reasonable thing to add I'd like to work on 
this with someone.

As noted: 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.

A second question would be: Is there anyone who would be willing to work 
on this with me?
Where would "we" or I start?

Thank you for taking the time to read and possibly answer,
Simon Sobisch

Maintainer GnuCOBOL



[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7183 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

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

[Ian Lance Taylor]

On Fri, May 27, 2022 at 12:17 AM Simon Sobisch via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> As noted: the first question is: is it reasonable to add support for
> GnuCOBOL?

It seems fine to me to add support for demangling GnuCOBOL symbol
names controlled by a DMGL option (options are defined in
include/demangle.h).


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

The demangler doesn't see a list of symbol names, it only sees a
single string at a time.  If GnuCOBOL symbols are to be demangled by
default, then there must be a clear distinction between COBOL names
and other names.  For example, C++ demangled names, with a few minor
exceptions, always start with "_Z".  If there is no such marker then
we would have to require that the names only be demangle with a DMGL
option.  There could be a corresponding command line option for
c++filt.

Ian

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

[Eric Gallager]

On Fri, May 27, 2022 at 3:17 AM Simon Sobisch via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> Hi fellow hackers,
>
> first of all: I'm not sure if this is the correct mailing list for this
> question, but I did not found a separate one and
> gnu.org/software/libiberty redirects to
> https://gcc.gnu.org/onlinedocs/libiberty.pdf - so I'm here.
> If there's a better place for this: please drop a note.
>
> I've never "worked" with libiberty directly but am sure I'm using it
> quite regularly with various tools including GDB and valgrind.
> Therefore I currently cannot send a patch for the function name
> demangling, but if this is a reasonable thing to add I'd like to work on
> this with someone.
>
> As noted: 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.

> A second question would be: Is there anyone who would be willing to work
> on this with me?
> Where would "we" or I start?
>
> Thank you for taking the time to read and possibly answer,
> Simon Sobisch
>
> Maintainer GnuCOBOL
>
>

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

[Simon Sobisch]

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