Feature #1045
Wire up debug info on lttng_ust_cyg_profile event fields
0%
Description
#lttng paste
09:56 < rnsanchez> is there a default procedure for "hydrating" instrument-functions traces like this?
09:56 < rnsanchez> [13:54:09.866652414] (+0.000001178) priminho lttng_ust_cyg_profile:func_exit: { cpu_id = 1 }, { addr = 0x46BB90, call_site = 0x46BF7B }
09:56 < rnsanchez> (kind of replacing the addr with their proper symbols)
09:57 < milian> rnsanchez: I'm not an lttng dev, but could imagine that one would be able to write that by analyzing mmap + openat to find the offset into a library, which you can then feed into addr2line, or libdw/libbacktrace
09:59 < rnsanchez> I could propably pass it (babeltrace) through some script to do that. but since the trace is huge (and this is not even a "real" trace), I was wondering if there is a better way to do that
09:59 < milian> I'd also be interested in that
10:00 < rnsanchez> well maybe there is one. building a symbol-table cache for the known things (a binary of special interest) and then feeding babeltrace through awk, replacing the symbols found with their names
10:01 < rnsanchez> some would miss, of course, but perhaps a good amount would help
10:46 < Compudj> rnsanchez, milian: currently, babeltrace is a bit "hardwired" to the "ip" context for symbol resolution
10:46 < Compudj> but all the infrastructure code is there
10:49 < Compudj> see babeltrace: formats/ctf-text/types/integer.c
10:49 < Compudj> there is a call to ctf_text_integer_write_debug_info
10:50 < Compudj> implemented in include/babeltrace/trace-debug-info.h
10:50 < Compudj> it checks if integer_definition->debug_info_src is non-null
10:51 < Compudj> this is wired up in lib/debug-info.c register_event_debug_infos()
10:51 < Compudj> it is where it is tied to the "ip" context
10:51 < Compudj> it should be extended to be tied to the lttng_ust_cyg_profile event fields too
Updated by Anonymous about 4 years ago
Just to clarify, since this could apply to Trace Compass too: currently the debug-info analysis needs both the ip and vpid contexts. ip to get the actual instruction pointer location, and vpid to match the library statedump (and dlopen/dlclose events) and subsequent events to the correct process, as there could be more than one process in the same trace, each one with their own loaded libraries.
Is the suggestion here to allow replacing the ip context in lttng_ust_cyg_profile events by the addr fields? I did some tests and in all cases the ip context and addr field values seem to always be the same, so that part would be fine.
However the vpid context would remain mandatory, so a completely context-less trace still wouldn't allow symbol resolution. Is this correct?
Updated by Ricardo Nabinger Sanchez about 4 years ago
A crude example of the intended behavior:
[21:02:31.879210496] (+0.000000285) priminho lttng_ust_cyg_profile:func_entry: { cpu_id = 1 }, { addr = _assert_VSB_state, call_site = VSB_vprintf }
[21:02:31.879210778] (+0.000000282) priminho lttng_ust_cyg_profile:func_exit: { cpu_id = 1 }, { addr = _assert_VSB_state, call_site = VSB_vprintf }
[21:02:31.879211064] (+0.000000286) priminho lttng_ust_cyg_profile:func_entry: { cpu_id = 1 }, { addr = _vsb_indent, call_site = VSB_vprintf }
[21:02:31.879211346] (+0.000000282) priminho lttng_ust_cyg_profile:func_exit: { cpu_id = 1 }, { addr = _vsb_indent, call_site = VSB_vprintf }
[21:02:31.879211986] (+0.000000640) priminho lttng_ust_cyg_profile:func_exit: { cpu_id = 1 }, { addr = VSB_vprintf, call_site = VSB_printf }
[21:02:31.879212266] (+0.000000280) priminho lttng_ust_cyg_profile:func_exit: { cpu_id = 1 }, { addr = VSB_printf, call_site = build_vident }
[21:02:31.879212576] (+0.000000310) priminho lttng_ust_cyg_profile:func_entry: { cpu_id = 1 }, { addr = VSB_printf, call_site = 0x46A4D0 }
Not all symbols could be resolved in the example above.