Re: RFA/RFC: Add stack recursion limit to libiberty's demangler

[Nick Clifton <nickc at redhat dot com>]

Hi Pedro, Hi Tom,

> Pedro> E.g., in GDB, loading big binaries, demangling is very high
> Pedro> in profiles, and so we've kicked around the desire to parallelize
> Pedro> it

I did consider this, but I encountered two problems:

  1. I wanted users of the demangling functions to be able to change
     the recursion limit.  So for example in environments with a very
     limited amount of stack space the limit could be reduced.  This
     is one of the purposes of the cplus_demangle_set_recursion_limit()
     function.

     Since a new d_info structure is created every time a string is demangled
     the only way to implement cplus_demangle_set_recursion_limit would
     be to have it set the value that is used to initialize the field in
     the structure, which is basically back to where we are now.

  2. I wanted to be able to access the recursion limit from code
     in cplus-dem.c, which does not use the d_info structure.  This was
     the other purpose of the cplus_demangler_set_recursion_limit()
     function - it allows the limit to be read without changing it.

As an alternative I did consider adding an extra parameter to the 
cplus_demangle(), cplus_demangle_opname() and related functions.  But
this would make them non-backwards compatible and I did not want to 
do that.

I would imagine that changing the recursion limit would be a very
rare event, possibly only ever done once in an executable's runtime, 
so I doubt that there will ever be any real-life thread safety 
problems associated with it.  But I do understand that this is just
an assumption, not a guarantee.

Cheers
  Nick