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