From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31750 invoked by alias); 7 Jul 2009 21:35:02 -0000 Received: (qmail 31692 invoked by uid 22791); 7 Jul 2009 21:35:01 -0000 X-SWARE-Spam-Status: No, hits=-0.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_46,J_CHICKENPOX_56,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-fx0-f207.google.com (HELO mail-fx0-f207.google.com) (209.85.220.207) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 07 Jul 2009 21:34:55 +0000 Received: by fxm3 with SMTP id 3so3518964fxm.26 for ; Tue, 07 Jul 2009 14:34:51 -0700 (PDT) Received: by 10.103.160.9 with SMTP id m9mr3666221muo.53.1247002491318; Tue, 07 Jul 2009 14:34:51 -0700 (PDT) Received: from nowhere (253.24.192-77.rev.gaoland.net [77.192.24.253]) by mx.google.com with ESMTPS id s10sm8344389muh.27.2009.07.07.14.34.49 (version=SSLv3 cipher=RC4-MD5); Tue, 07 Jul 2009 14:34:50 -0700 (PDT) Received: by nowhere (nbSMTP-1.00) for uid 1000 (using TLSv1/SSLv3 with cipher RC4-MD5 (128/128 bits)) fweisbec@gmail.com; Tue, 7 Jul 2009 23:34:50 +0200 (CEST) Date: Tue, 07 Jul 2009 21:35:00 -0000 From: Frederic Weisbecker To: Masami Hiramatsu Cc: Ingo Molnar , Steven Rostedt , lkml , systemtap , kvm , DLE , Ananth N Mavinakayanahalli , Christoph Hellwig , Tom Zanussi Subject: Re: [PATCH -tip -v10 7/7] tracing: add kprobe-based event tracer Message-ID: <20090707213447.GC7412@nowhere> References: <20090701010838.32547.62843.stgit@localhost.localdomain> <20090701010923.32547.74203.stgit@localhost.localdomain> <20090707073103.GA6173@nowhere> <4A53A830.3000305@redhat.com> <20090707202008.GE6184@nowhere> <4A53B338.4060803@redhat.com> <20090707205851.GF6184@nowhere> <4A53BEAD.7030404@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A53BEAD.7030404@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2009-q3/txt/msg00058.txt.bz2 On Tue, Jul 07, 2009 at 05:31:25PM -0400, Masami Hiramatsu wrote: > Frederic Weisbecker wrote: > > On Tue, Jul 07, 2009 at 04:42:32PM -0400, Masami Hiramatsu wrote: > >> Frederic Weisbecker wrote: > >>> On Tue, Jul 07, 2009 at 03:55:28PM -0400, Masami Hiramatsu wrote: > >>>> Frederic Weisbecker wrote: > >>>>>> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h > >>>>>> index 206cb7d..65945eb 100644 > >>>>>> --- a/kernel/trace/trace.h > >>>>>> +++ b/kernel/trace/trace.h > >>>>>> @@ -45,6 +45,8 @@ enum trace_type { > >>>>>> TRACE_POWER, > >>>>>> TRACE_BLK, > >>>>>> TRACE_KSYM, > >>>>>> + TRACE_KPROBE, > >>>>>> + TRACE_KRETPROBE, > >>>>>> > >>>>>> __TRACE_LAST_TYPE, > >>>>>> }; > >>>>>> @@ -227,6 +229,22 @@ struct trace_ksym { > >>>>>> char ksym_name[KSYM_NAME_LEN]; > >>>>>> char p_name[TASK_COMM_LEN]; > >>>>>> }; > >>>>>> +#define TRACE_KPROBE_ARGS 6 > >>>>>> + > >>>>>> +struct kprobe_trace_entry { > >>>>>> + struct trace_entry ent; > >>>>>> + unsigned long ip; > >>>>>> + int nargs; > >>>>>> + unsigned long args[TRACE_KPROBE_ARGS]; > >>>>> > >>>>> I see that you actually make use of arg as a dynamic sizeable > >>>>> array. > >>>>> For clarity, args[TRACE_KPROBE_ARGS] could be args[0]. > >>>>> > >>>>> It's just a neat and wouldn't affect the code nor the data > >>>>> but would be clearer for readers of that code. > >>>> Hmm. In that case, I think we'll need a new macro for field > >>>> definition, like TRACE_FIELD_ZERO(type, item). > >>> > >>> > >>> You mean that for trace_define_field() to describe fields of events? > >>> Actually the fields should be defined dynamically depending on how > >>> is built the kprobe event (which arguments are requested, how many, > >>> etc..). > >> Yeah, if you specified a probe point with its event name, the tracer > >> will make a corresponding event dynamically. There are also anonymous > >> probes which don't have corresponding events. For those anonymous > >> probes, I need to define two generic event types(kprobe and kretprobe). > >> > >> Thank you, > > > > > > Ok. Btw, why do you need to define those two anonymous events? > > Actually your event types are always dynamically created. > > Those you defined through TRACE_FORMAT_EVENT are only "ghost events", > > they only stand there as a abstract pattern, right? > > > > Not always created. > > Below command will create an event "event1"; > p probe_point:event1 a1 a2 a3 ... > /debug/tracing/kprobe_events > > But next command doesn't create. > p probe_point a1 a2 a3 ... > /debug/tracing/kprobe_events Aah, ok. > This just inserts a kprobe to probe_point. the advantage of this > "simple" command is that you never be annoyed by making different > name for new events :-) Indeed. But speaking about that, may be you could dynamically create a name following this simple model: func+offset Unless we can set several kprobes on the exact same address?