Project

General

Profile

Actions
Copy link

Feature #1045

open

Wire up debug info on lttng_ust_cyg_profile event fields

Added by Mathieu Desnoyers over 8 years ago. Updated over 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
07/13/2016
Due date:
% Done:

0%

Estimated time:

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

Actions
Copy link
 #1

Updated by Mathieu Desnoyers over 8 years ago

  • Tracker changed from Bug to Feature
Actions
Copy link
 #2

Updated by Anonymous over 8 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?

Actions
Copy link
 #3

Updated by Ricardo Nabinger Sanchez over 8 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.

Actions
Copy link
 #4

Updated by Erica Bugden over 1 year ago

These items seem like they may be relevant to this discussion:

Actions
Copy link
 #5

Updated by Mathieu Desnoyers over 1 year ago

I don't think we should add more special-cases in the current babeltrace code base (reading lttng traces in CTF 1.8) for now to target additional fields by event and field names.

When lttng-ust moves to CTF2, we will likely want to annotate each "instruction pointer" field with user attributes that lets babeltrace know that those fields must be decoded as instruction pointers with debug info (and symbols) associated. We can then use that new information to decode all instruction pointers with the relevant symbol information.

So this is a feature request that will be unblocked by adding CTF 2 support into babeltrace and lttng, and then annotating the relevant lttng fields, and updating the babeltrace debug-info plugin to use this annotation.

Actions
Copy link

Also available in: Atom PDF