RFA/RFC: Add stack recursion limit to libiberty's demangler
Ian Lance Taylor
ian@airs.com
Thu Nov 29 22:18:00 GMT 2018
More information about the Binutils mailing list
Thu Nov 29 22:18:00 GMT 2018
- Previous message (by thread): RFA/RFC: Add stack recursion limit to libiberty's demangler
- Next message (by thread): RFA/RFC: Add stack recursion limit to libiberty's demangler
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): RFA/RFC: Add stack recursion limit to libiberty's demangler
- Next message (by thread): RFA/RFC: Add stack recursion limit to libiberty's demangler
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list