Re: libiberty: Would it be reasonable to add support for GnuCOBOL function name demangling?
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
Re: libiberty: Would it be reasonable to add support for GnuCOBOL function name demangling?
On Fri, May 27, 2022 at 3:17 AM Simon Sobisch via Gcc-patches 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?
On Fri, May 27, 2022 at 12:17 AM Simon Sobisch via Gcc-patches 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
