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

[Ian Lance Taylor <iant@google.com>]

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