Hi Mathieu,
thanks for your reply, see comments below.
On 03/17/2011 02:07 PM, Mathieu Desnoyers wrote:
* Paul Wögerer ([email protected]) wrote:
Hi,
I'm trying to use LTTng UST as a backend for function call tracing. The
following pseudocode shows what we basically to:
ustcmd_set_marker_state( "call_trace", call, enter, 1, pid );
ustcmd_set_marker_state( "call_trace", call, inside, 1, pid );
ustcmd_set_marker_state( "call_trace", call, exit, 1, pid );
ustcmd_create_trace( "call_trace", pid );
ustcmd_start_trace( "call_trace", pid );
...
... Lots of auto-generated code that makes use of call.enter/inside/exit
markers
...
ustcmd_stop_trace( "call_trace", pid );
ustcmd_destroy_trace( "call_trace", pid );
This works very well in general but whenever an executable runs only for
a very short amount of time I run into troubles with stopping/destroying
my "call_trace" properly.
This is caused by the fact that stop/destroy_trace runs before buffer
consumption completed on the ust-consumerd side. This is easy to prevent
by some code that implements waiting for buffer consumption. Fortunately
this is already available in tracectl.c keepalive().
The following patch puts the "waiting for buffer consumption" code into
its own function and makes it visible externally via ust/ustctl.h. Using
function wait_for_buffer_consumption() before stop/destroy_trace solves
the problem for me.
Please apply the patch from the attachment to the ust trunk to make
wait_for_buffer_consumption()available for everyone.
This brings up two interesting questions:
a) Do we want to expose the ustcmd_* API to applications at this point
in the development, given the changes that are coming ? The expected
way for an application to use tracing would be to interact with the
external app/lib responsible for tracing rather than controlling this
internally.
While I think the non-intrusive approach that is currently under
development is a good thing in terms of usability I also see the
advantages of having full control where exactly in the sources I want to
start and stop tracing. This feature of the current version of libust
should not be abounded. It gives a lot of flexibility that would be
hardly missed.
It should be possible to have an executable running that is under
external trace control while at the same time allowing the executable to
create its own specialized traces based on some conditions that only the
executable itself knows.
b) Do we want to *ever* expose the ustcmd_* API ? I'm not so sure,
because it drastically changes the way we think about libust.
In the upcoming future, my vision is that libust's only API used by
the application is trace_event/markers. Everything else should be
internal to libust, only presented to the ltt-sessiond through
the communication socket. I'm concerned about the fact that
supporting more than that will send us deep into both API _and_
locking hells.
Would that interface allow me to _dynamically_ declare and use markers
inside my code as I can do now with ustcmd_set_marker_state ?
For example:
if(do_call_trace)
{
ustcmd_set_marker_state( "my_trace", call, enter, 1, pid );
ustcmd_set_marker_state( "my_trace", call, inside, 1, pid );
ustcmd_set_marker_state( "my_trace", call, exit, 1, pid );
}
if(do_function)
{
ustcmd_set_marker_state( "my_trace", function, prolog, 1, pid );
ustcmd_set_marker_state( "my_trace", function, epilog, 1, pid );
}
ustcmd_create_and_start_trace( "my_trace", pid );
--
Thanks,
PaulW
_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
