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

[Martin Jambor]

Hello,

On Fri, Apr 08 2022, Pedro Alves wrote:
> 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

thanks for the pointer, I also stumbled across these only recently.
Indeed it seems it may be necessary to also have a variant that would
have to rely on alloca in the main driving loop to allocate the explicit
stack... which will make the code a bit ugly but hopefully not that
much.

But this can be handled incrementally once we can get the normal mode of
operation working.

Thanks again,

Martin


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