Bug 222563 - libcxxrt abi::__cxa_demangle() does not successfully demangle names
Summary: libcxxrt abi::__cxa_demangle() does not successfully demangle names
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Many People
Assignee: Ed Maste
Depends on:
Blocks: 231027
  Show dependency treegraph
Reported: 2017-09-24 17:19 UTC by Ian Lepore
Modified: 2018-08-31 20:18 UTC (History)
3 users (show)

See Also:

Small c++ program to demonstrate the problem (523 bytes, text/x-c++src)
2017-09-24 17:19 UTC, Ian Lepore
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Lepore freebsd_committer 2017-09-24 17:19:59 UTC
Created attachment 186671 [details]
Small c++ program to demonstrate the problem

The attached small c++ program should print the demangled names of a couple symbols when it runs, but it does not:

# make tester && ./tester
c++ -O -pipe  tester.cc  -o tester
name '3Foo' = '3Foo' status=-2
name 'Z4mainE3Bar' = '(null)' status=-2

The current demangling code in libcxxrt is a snapshot of the libelftc demangler from 10-ish years ago.  If you replace it with the current libelftc demangling code and make some other small changes you can get abi::__cxa_demangle() to the point where it returns the same slightly-less-wrong results as c++filt (see PR 222562).

Part of the problem with abi::__cxa_demangle() is that it is not correctly glued to the libelftc demangling code.  The demangler wants to see a prefix on the symbol name, like what you see in nm(1) output.  That is, typeid(bar).name() returns "Z4mainE3Bar" and the demangle code expects "_ZTSZ4mainE3Bar".  (This is the small change I referred to above.)

One potential fix for this would be to examine llvm's libcxxabi and possibly import its demangler (or maybe the entire library).  I gather this libcxxabi didn't exist when we created/imported libcxxrt.