This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: RFA/RFC: Add stack recursion limit to libiberty's demangler
- From: Ian Lance Taylor <ian at airs dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Nick Clifton <nickc at redhat dot com>, gcc-patches at gcc dot gnu dot org, binutils at sourceware dot org, matz at gcc dot gnu dot org, sgayou at redhat dot com, jason at redhat dot com
- Date: Thu, 29 Nov 2018 14:18:13 -0800
- Subject: Re: RFA/RFC: Add stack recursion limit to libiberty's demangler
- References: <87sgzkszbh.fsf@redhat.com> <8bf7952a-5cf1-27b9-e385-e1e12536bf3f@redhat.com>
Pedro Alves <palves@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