GSoC, Make cp-demangle non-recursive and async-signal safety

[Pedro Alves <pedro@palves.net>]

Hi!

I noticed the discussions about making cp-demangle use malloc/free instead of recursion,
and I wonder about signal handlers, and I don't see that mentioned in
https://gcc.gnu.org/wiki/SummerOfCode's description of the project.  

See my question to Ian a few years back, here, and his answer:

https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00696.html

~~~
 Ian says:
 > Pedro says:
 > Ian earlier mentioned that we've wanted to avoid malloc because some
 > programs call the demangler from a signal handler, but it seems like
 > we already do, these functions already aren't safe to use from
 > signal handlers as is.  Where does the "we can't use malloc" idea
 > come from?  Is there some entry point that avoids
 > the malloc/realloc/free calls?

 cplus_demangle_v3_callback and cplus_demangle_print_callback.
~~~

Grepping the gcc tree, I see that libsanitizer uses those entry points.

Is async-signal safety no longer a consideration/concern?  Or will those entry points
continue to work without calling malloc/free somehow?