CODEWITHSUNDEEP
c++objdumpname-manglingnmc++filt
hassec
hassec

Reputation: 766

Failure to demangle symbol name in library (nm, objdump, c++filt)

I noticed non-demangled functions in my output of perf script and originally thought perf might be doing something wrong.
But, looking deeper into some of the *.so files, I've been able to reproduce the problem with c++filt -t, nm -C, and objdump -D -C.

I'm a bit lost as to what could possibly be going wrong in the demangling process.
One of the symbols that isn't getting demangled is:

_ZZNK5Gaudi10Functional7details16MultiTransformerIFSt5tupleIJSt6vectorIN4LHCb14VPLightClusterESaIS6_EESt5arrayIjLm53EEEERK12EventContextRKNS5_8RawEventERK4DeVPENS0_6Traits4use_IJNS5_7DetDesc21useConditionHandleForIJSI_EEENSM_11BaseClass_tINSO_23ConditionAccessorHolderI10FixTESPathINS_9AlgorithmEEEEEEEEELb0EE7executeESE_ENKUlDpRT_E_clIJK21DataObjectWriteHandleIS8_S8_EKS15_ISA_SA_EEEEDaS12_

The library was compiled with GCC 10.1. But if I compile with clang 11, I can find the same symbol in objdump -D -C.

I'm a bit at a dead end now, so any suggestions as to what I could possibly check would be really appreciated. :)

Upvotes: 2

Views: 1599

Answers (1)

hassec
hassec

Reputation: 766

Resolved by using the tool suggested in the comments.

llvm-cxxfilt also works and might be already available on some machines.

c++filt, nm, perf, and objdump use functionality that is implemented in libiberty which is part of GCC. Thus I've filed a bug report there: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102851

Upvotes: 3

Related Questions