Unable to demangle some functions

[RedBeard0531]

The shortest I see is

_ZSt12__apply_implIZN5mongo20stacktrace_test_util25StackTraceSigAltStackTest10tryHandlerEPFviP9siginfo_tPvEEUlvE_St5tupleIJEETpTnmJEEDcOT_OT0_St16integer_sequenceImJXspT1_EEE

c++trace seems to choke on this well, but llvm-cxxtrace demangles to

decltype(auto) std::__apply_impl<mongo::stacktrace_test_util::StackTraceSigAltStackTest::tryHandler(void (*)(int, siginfo_t*, void*))::'lambda'(), std::tuple<>>(mongo::stacktrace_test_util::StackTraceSigAltStackTest::tryHandler(void (*)(int, siginfo_t*, void*))::'lambda'()&&, std::tuple<>&&, std::integer_sequence<unsigned long, ...>)

If it helps, it is this function from libstdc++'s <tuple> compiled with clang.

Here are a few more examples that failed to demangle. They all seem to involve lambda's but I don't know if that is why it is choking. Some functions with lambdas are correctly demangled.

> llvm-cxxfilt

_ZZN5mongo4stdx6threadC1IZNS_20stacktrace_test_util25StackTraceSigAltStackTest10tryHandlerEPFviP9siginfo_tPvEEUlvE_JETnNSt9enable_ifIXntsr3stdE9is_same_vIS1_NSt5decayIT_E4typeEEEiE4typeELi0EEESD_DpOT0_ENUlvE_clEv
mongo::stdx::thread::thread<mongo::stacktrace_test_util::StackTraceSigAltStackTest::tryHandler(void (*)(int, siginfo_t*, void*))::'lambda'(), 0>(mongo::stacktrace_test_util::StackTraceSigAltStackTest::tryHandler(void (*)(int, siginfo_t*, void*))::'lambda'())::'lambda'()::operator()()

_ZSt13__invoke_implIvZN5mongo4stdx6threadC1IZNS0_20stacktrace_test_util25StackTraceSigAltStackTest10tryHandlerEPFviP9siginfo_tPvEEUlvE_JETnNSt9enable_ifIXntsr3stdE9is_same_vIS2_NSt5decayIT_E4typeEEEiE4typeELi0EEESE_DpOT0_EUlvE_JEESE_St14__invoke_otherOT0_DpOT1_
mongo::stacktrace_test_util::StackTraceSigAltStackTest::tryHandler(void (*)(int, siginfo_t*, void*))::'lambda'() std::__invoke_impl<void, mongo::stdx::thread::thread<mongo::stacktrace_test_util::StackTraceSigAltStackTest::tryHandler(void (*)(int, siginfo_t*, void*))::'lambda'(), 0>(mongo::stacktrace_test_util::StackTraceSigAltStackTest::tryHandler(void (*)(int, siginfo_t*, void*))::'lambda'())::'lambda'()>(std::__invoke_other, mongo::stdx::thread::thread<mongo::stacktrace_test_util::StackTraceSigAltStackTest::tryHandler(void (*)(int, siginfo_t*, void*))::'lambda'(), 0>(mongo::stacktrace_test_util::StackTraceSigAltStackTest::tryHandler(void (*)(int, siginfo_t*, void*))::'lambda'())::'lambda'()&&)

_ZNSt6thread11_State_implINS_8_InvokerISt5tupleIJZN5mongo4stdx6threadC1IZNS3_20stacktrace_test_util25StackTraceSigAltStackTest10tryHandlerEPFviP9siginfo_tPvEEUlvE_JETnNSt9enable_ifIXntsr3stdE9is_same_vIS5_NSt5decayIT_E4typeEEEiE4typeELi0EEESH_DpOT0_EUlvE_EEEEE6_M_runEv
std::thread::_State_impl<std::thread::_Invoker<std::tuple<mongo::stdx::thread::thread<mongo::stacktrace_test_util::StackTraceSigAltStackTest::tryHandler(void (*)(int, siginfo_t*, void*))::'lambda'(), 0>(mongo::stacktrace_test_util::StackTraceSigAltStackTest::tryHandler(void (*)(int, siginfo_t*, void*))::'lambda'())::'lambda'()>>>::_M_run()

[jeremy-rifkin]

Hi,
By c++trace and llvm-cxxtrace I'm guessing you mean c++filt / llvm-cxxfilt?

For gcc and clang cpptrace uses the demangling routine provided by the compiler via abi::__cxa_demangle. A failure to demangle generally indicates a problem that has to be reported upstream. If c++filt is not demangling it but llvm-cxxfilt does, that would confirm it being a problem with gcc's demangler. It would also suggest this can be worked around by using llvm and libc++.

[RedBeard0531]

I'll go ahead and report upstream. This seems to be a difference in how clang and gcc mangle that function (which may be allowed because lambdas have no linkage). For some reason I thought you had your own demangler implementation but I reread the docs and it clearly says that you don't.

That said, you may want to consider pulling the function name from the debug info rather than demangling the raw symbol.

[jeremy-rifkin]

Thanks for reporting upstream!

I briefly looked at doing some custom demangling but it’s a lot of work for relatively little benefit.

I previously looked at what you’re describing with getting the name from the debug info but ultimately using the linkage name and demangling that has been robust. It’s more than just the function name the user needs to see, otherwise you’ll see a lot of common names like operator=. At the very least scope information needs to be captured. That’s something that can be tracked while traversing the dwarf tree but this complicates an optimization cpptrace uses for quicker function lookups. Many users want to see template arguments and parameters too and rebuilding those from the dwarf info is a hassle.

[jeremy-rifkin]

Gcc and clang’s demanglers are good but from time to time I have seen them failing to demangle more contrived symbols. Usually I see compiler explorer users making bug reports about this, and from time to time I am testing something on CE that the demangler isn’t demangling. Usually this is solved by updating the demangler being used. I’m not sure what’s tripping up gcc here exactly. Lambdas don’t have linkage but the itanium ABI does specify some about how closure types are named and for the most part both gcc and llvm’s demanglers are happy with symbols from the other compiler.

[jeremy-rifkin]

Will close as completed for now