Hello!
On Wed, Oct 22, 2014 at 10:22 AM, S wrote:
> Could you please elaborate on the method you suggested? As you said,
> systemtap does not resolve inline functions. So, the a.bt file from your
> sample-bt does not contain the stack information for the inlined functions.
I think we need to distinguish two different things: frame addresses
and their corresponding symbol names (or function names).
What I've said is
1. systemtap always produce frame addresses and no frame addresses
should be missing. inlined functions do not have their own frame
addresses (otherwise they are not inlined, by definition).
2. non-inlined functions share exactly the same frame address with
their parent functions, which means some frame addresses can resolve
to more than 1 function,
3. sysetmtap only resolves the frame address to non-inlined functions'
symbol names. it does not bother check out the debug info to further
resolve some of the frame addresses to inlined function names.
In summary, systemtap already provides all the information we need. It
just does not do the further symbol resolving for inlined functions.
What addr2line is useful here is that we can use it to further resolve
the frame addresses to more symbol names (i.e., for those inlined
functions).
> Could you please share your thoughts about how to use addr2line to post
> processing this info?
>
I just committed the "resolve-inlines" tool to
nginx-systemtap-toolkit's git repos:
https://github.com/openresty/nginx-systemtap-toolkit/commit/80bb83c
Feel free to try it out. PIC support is still a TODO because it
requires a bit more work. (Patches welcome!)
One caveat is that C compilers might not generate accurate debug info
for massively optimized inlined functions.
>
> It would be great if you could add this into sample-bt, and it will be a
> great feature!
This requires quite some extra CPU cycles and I prefer not putting
this into sample-bt that has to be run online. The resolve-inlines
utility given above, on the other hand, can be run offline.
Regards,
-agentzh
