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