From mboxrd@z Thu Jan  1 00:00:00 1970
From: compudj@krystal.dyndns.org (Mathieu Desnoyers)
Date: Tue, 4 Aug 2009 09:05:10 -0400
Subject: [ltt-dev] Tracing thread name
In-Reply-To: <4A78099B.4@parrot.com>
References: <4A76E42D.7010908@parrot.com> <20090803134843.GB23455@Krystal>
	<4A78099B.4@parrot.com>
Message-ID: <20090804130510.GA23396@Krystal>

* Matthieu CASTET (matthieu.castet at parrot.com) wrote:
> Hi Mathieu,
> 
> Mathieu Desnoyers a ?crit :
> > * Matthieu CASTET (matthieu.castet at parrot.com) wrote:
> >> Hi,
> >>
> >> I use ltt on a 2.6.27 on an arm architecture.
> >> It works quite well, but I have a minor problem :
> >>
> >> my application sets thread name with prctl PR_SET_NAME. But ltt viewer
> >> doesn't seem to saw it.
> >>
> > 
> > Hrm, I guess we might want to instrument set_task_comm as you propose to
> > get the correct process name, but if this gets us the thread name, I
> > think it's only an implementation side-effect:
> 
> > The way LTTng handles thread names is by adding a userspace "thread
> > branding" event. It should be executed at thread startup. The downside
> > of the current LTTng approach is that we cannot know the name of threads
> > already executing before we started tracing.
> > 
> 
> Do you know if it is possible to patch my version to add such feature ?
> 
> I saw that the name already change in the trace before/after an exec.
> How lltv get the new name ?
> With "fs.exec" tracepoint ?
> In that case I could fake a "fs.exec" tracepoint in set_task_comm.

A better solution : you add a new event in both lttng and lttv, and
modify state.c to support your new event. The current event to brand
thread is named "userspace.thread_brand". Look for this in LTTV to see
all the sites that need to support the new event (there are very few).

Mathieu

> 
> Thanks
> 
> Matthieu
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68