LTTng » LTTng-UST

When an already running application gets traced with liblttng-ust-cyg-profile
function entry/exit instrumentation we should provide a way to reconstruct the
stack state at connection time. This can be achieved by using the backtrace
feature of glibc.

The following conversation on IRC motivated this feature request:

[09:51] <pwoegere> Compudj: Regarding http://git.lttng.org/?p=lttng-ust.git;a=blob;f=liblttng-ust-cyg-profile/lttng-ust-cyg-profile.c;h=d772e76b961a148d19bf04d56ae9481b697d99b5;hb=70d654f22a6b52beddfb86ec3daa453073c356d2#l39
[09:52] <pwoegere> Compudj: There is a disadvantage not to pass the return address on lttng_ust_cyg_profile:func_exit
[09:52] <pwoegere> Compudj: Think about the use case where you start recording in the middle of the application ...
[09:53] <pwoegere> Compudj:
[09:53] <pwoegere> All the lttng_ust_cyg_profile:func_exit events where
[09:53] <pwoegere> there is no corresponding func_entry (because it was emitted before the
[09:53] <pwoegere> attach happend) are basically worthless.
[09:56] <pwoegere> Compudj: If you also pass the call_site to func_exit to you will have useful func_exit events even when you don't have the corresponding func_entry
[11:40] <Compudj> pwoegere: yes, it's a question of trade-off
[11:41] <Compudj> pwoegere: is it worth it to almost double the size of the traces (and thus double the throughput needed) in order to handle the few func_exit events that would happen to be there at trace start without matching func_entry ?
[11:41] <Compudj> pwoegere: in my opinion, the saving in trace bandwidth is far more important
[12:20] <pwoegere> Compudj: We could use something like "man 3 backtrace" to dump the stack state at record start (attach) time. This would allow to reconstruct the missed stack state.
[12:24] <Compudj> pwoegere: it sounds like an excellent idea!
[12:24] <Compudj> pwoegere: could you open a feature request on bugs.lttng.org along with this reference ?