Pedro Alves <pal...@redhat.com> writes:
> Hi Nick,
>
> On 11/29/2018 03:01 PM, Nick Clifton wrote:
>> static struct demangle_component *
>> d_function_type (struct d_info *di)
>> {
>> - struct demangle_component *ret;
>> + static unsigned long recursion_level = 0;
>
> Did you consider making this be a part of struct d_info instead?
> IIRC, d_info is like a "this" pointer, passed around pretty
> much everywhere.
>
> I think going in the direction of making the demangler harder to use
> in an efficient thread-safe manner is undesirable, even if the feature
> is optional. E.g., in GDB, loading big binaries, demangling is very high
> in profiles, and so we've kicked around the desire to parallelize
> it (e.g., by parallelizing the reading/interning of DSO files, instead of
> reading all of them sequentially). Having to synchronize access to the
> demangler would be quite unfortunate. If possible, it'd be great
> to avoid making work toward that direction harder. (Keeping in mind that
> if this recursion detection feature is useful for binutils, then it should
> also be useful for GDB.)
I agree. Using static variables here seems problematic. Right now as
far as I know the demangler has no static variables at all.
Ian
