On Tue, Dec 11, 2018 at 3:05 AM Pedro Alves <pal...@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
