search

ianlancetaylor / demangle

C++ symbol name demangler written in Go
BSD 3-Clause "New" or "Revised" License
166 stars 24 forks source link

lambdas are not minimized #5

Closed dvyukov closed 6 years ago

dvyukov commented 6 years ago

I am using:

        name := demangle.Filter(frame.Func, demangle.NoParams, demangle.NoTemplateParams)

with the intent of getting reasonable traces (i.e. not a dozen of lines per frame) for heavy C++ code, e.g.:

bt#04: 0x001619ba SocketDispatcher::WriteSelfLocked object/socket_dispatcher.cpp:275
bt#05: 0x00161a39 SocketDispatcher::Write object/socket_dispatcher.cpp:212
bt#06: 0x0018bf7b sys_socket_write syscalls/socket.cpp:68
bt#07: [ inline ] operator() syscall-kernel-wrappers.inc:204
bt#07: [ inline ] socket_write syscalls/syscalls.cpp:60
bt#07: 0x0016f9a4 wrapper_socket_write syscall-kernel-wrappers.inc:206
bt#08: 0x00115e7f x86_syscall syscall-kernel-branches.S:34

but in some cases I am getting something like (which is not qualified as reasonable):

bt#12: [ inline ] ForEachChildInLocked<fbl::DoublyLinkedList<JobDispatcher*, JobDispatcher::ListTraitsRaw>, JobDispatcher::EnumerateChildren(JobEnumerator*, bool)::<lambda(fbl::RefPtr<JobDispatcher>)> > object/job_dispatcher.cpp:94
bt#12: 0x001553f5 JobDispatcher::EnumerateChildren object/job_dispatcher.cpp:388
bt#13: [ inline ] operator() object/job_dispatcher.cpp:394
bt#13: [ inline ] ForEachChildInLocked<fbl::DoublyLinkedList<JobDispatcher*, JobDispatcher::ListTraitsRaw>, JobDispatcher::EnumerateChildren(JobEnumerator*, bool)::<lambda(fbl::RefPtr<JobDispatcher>)> > object/job_dispatcher.cpp:94
bt#13: 0x001553f5 JobDispatcher::EnumerateChildren object/job_dispatcher.cpp:388
bt#14: [ inline ] operator() object/job_dispatcher.cpp:394
bt#14: [ inline ] ForEachChildInLocked<fbl::DoublyLinkedList<JobDispatcher*, JobDispatcher::ListTraitsRaw>, JobDispatcher::EnumerateChildren(JobEnumerator*, bool)::<lambda(fbl::RefPtr<JobDispatcher>)> > object/job_dispatcher.cpp:94
bt#14: 0x001553f5 JobDispatcher::EnumerateChildren object/job_dispatcher.cpp:388
bt#15: [ inline ] operator() object/job_dispatcher.cpp:394
bt#15: [ inline ] ForEachChildInLocked<fbl::DoublyLinkedList<JobDispatcher*, JobDispatcher::ListTraitsRaw>, JobDispatcher::EnumerateChildren(JobEnumerator*, bool)::<lambda(fbl::RefPtr<JobDispatcher>)> > object/job_dispatcher.cpp:94
bt#15: 0x001553f5 JobDispatcher::EnumerateChildren object/job_dispatcher.cpp:388

I see that tests in demangle_test.go explicitly test for such behavior. Is it intentional? Shouldn't NoParams/NoTemplateParams also strip all that from lambdas and it's context?

FTR, one symbol example is _ZZ13platform_initENUlN6smbios11SpecVersionEPKNS_6HeaderERKNS_11StringTableEPvE_4_FUNES0_S3_S6_S7_.

ianlancetaylor commented 6 years ago

One of the goals of this package is to act, as much as possible, like as the demangler distributed with GCC. The file testdata/demangle-expected is copied from GCC. And indeed for your sample symbol _ZZ13platform_initENUlN6smbios11SpecVersionEPKNS_6HeaderERKNS_11StringTableEPvE_4_FUNES0_S3_S6_S7_ the c++filt program in this package produces the same output as the c++filt program that comes with GCC.

So maybe the first step is to file a bug against GCC asking that that demangler be changed. Or, of course, we could add another option here, but that doesn't seem like the best choice.