On Dienstag, 31. März 2020 15:39:18 CEST ahmadkhorrami wrote: > But the addresses do not match. Do you confirm this as a bug in > libdwarf,...? > > So I will ignore addresses without a matching symbol. But they do not > seem reliable! > > Could you tell me the name of the library that generates the raw > addresses, so that I can try to debug it? This is a platform specific question. There are multiple ways to unwind a stack. If you are on x86 then by default the .eh_frame section is available which holds the information necessary for unwinding. It doesn't depend on debug symbols, that's only used for symbolization and inline-frame resolution as Jiri indicated. That said, in the context of perf, there are multiple scenarios that can lead to broken unwinding: a) perf record --call-graph dwarf: unwinding can overflow the stack copy associated with every sample, so the upper end of the stack will be broken b) perf record --call-graph $any: when you are sampling on a precise event, such as cycles:P which is the default afaik, then on Intel with PEBS e.g. the stack copy may be "wrong". See e.g. https://lkml.org/lkml/2018/11/6/257 and the overall thread. This is not solved yet afaik and after my initial attempt at workarounding this issue I stopped looking into it and instead opted for explicitly sampling on the non-precise events when I record call graphs... You could try that too: do you see the issue when you run e.g.: `perf record --call-graph dwarf -e cycles` This should take the non-precise version for sampling but then at least the call stacks are correct. I.e. you trade the accuracy of the instruction pointer to which a sample points with reduced call stack breakage. c) bugs :) -- Milian Wolff | milian.wolff@xxxxxxxx | Senior Software Engineer KDAB (Deutschland) GmbH, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
|