[PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536
Ian Lance Taylor via binutils
binutils@sourceware.org
Tue Dec 11 14:26:00 GMT 2018
On Tue, Dec 11, 2018 at 3:05 AM Pedro Alves <palves@redhat.com> wrote:
>
> I noticed that the comment on top of __cxa_demangle says:
>
> "If OUTPUT_BUFFER is not long enough, it is expanded using realloc."
>
> and __cxa_demangle calls 'free'.
>
> And d_demangle, seemingly the workhorse for __cxa_demangle says:
>
> /* Entry point for the demangler. If MANGLED is a g++ v3 ABI mangled
> name, return a buffer allocated with malloc holding the demangled
> name. OPTIONS is the usual libiberty demangler options. On
> success, this sets *PALC to the allocated size of the returned
> buffer. On failure, this sets *PALC to 0 for a bad name, or 1 for
> a memory allocation failure, and returns NULL. */
>
> cplus_demangle, the entry point that gdb uses, also relies on malloc.
>
> 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.
Ian
More information about the Binutils
mailing list