From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31244 invoked by alias); 20 Apr 2010 14:01:10 -0000 Received: (qmail 31114 invoked by uid 22791); 20 Apr 2010 14:01:07 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from e23smtp09.au.ibm.com (HELO e23smtp09.au.ibm.com) (202.81.31.142) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Apr 2010 14:00:53 +0000 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [202.81.31.245]) by e23smtp09.au.ibm.com (8.14.3/8.13.1) with ESMTP id o3KE0oS9023481; Wed, 21 Apr 2010 00:00:50 +1000 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o3KE0njW1863846; Wed, 21 Apr 2010 00:00:49 +1000 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o3KE0nYh011181; Wed, 21 Apr 2010 00:00:49 +1000 Received: from linux.vnet.ibm.com ([9.124.31.43]) by d23av02.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with SMTP id o3KE0li1011144; Wed, 21 Apr 2010 00:00:48 +1000 Date: Tue, 20 Apr 2010 14:01:00 -0000 From: Srikar Dronamraju To: Dominique Toupin Cc: gdb@sourceware.org, "Frank Ch. Eigler" , systemtap@sourceware.org Subject: Re: Static/dynamic userspace/kernel trace Message-ID: <20100420140046.GB20675@linux.vnet.ibm.com> Reply-To: Srikar Dronamraju References: <20100419141356.GC4823@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20100419141356.GC4823@redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-04/txt/msg00063.txt.bz2 > > > I had a chat with Tom at the collaboration summit on tracing, he was > > suggesting I send you a mail on a recent GDB improvement. You might > > not be aware that user space dynamic tracepoint are now available in > > GDB, in process tracing if a few byte space is available to put a > > jump, if that space is not available then a trap between gdbserver > > and the process. With this addition all aspects of tracing seem to > > be covered: > > > > - static user space: LTTng UST > > - dynamic user space: GDB dynamic tracepoint I did go thro http://sources.redhat.com/gdb/current/onlinedocs/gdb.html#Set-Tracepoints but it says "The tracepoint facility is currently available only for remote targets. See Targets. In addition, your remote target must know how to collect trace data. This functionality is implemented in the remote stub; however, none of the stubs distributed with gdb support tracepoints as of this writing. " and "Some targets may support fast tracepoints, which are inserted in a different way (such as with a jump instead of a trap), that is faster but possibly restricted in where they may be installed. " So it possible to use GDB dynamic tracepoints on regular programs without using remote protocol? If not do you plans to implement this for non-remote targets? > > - static kernel: kernel static tracepoint/trace event > > - dynamic kernel: kprobe > > > > and conditional tracing is available for both kernel and user space. > > All right. > > > > Tom was saying uprobes/utrace can bring nice improvements for > > ptrace, for tracing it was not clear to me or Tom why we need > > uprobe/utrace or why systemtap needs it. Do you have a use case > > where the above tracing cannot be use and uprobe/utrace is needed > > instead? Since gdb tracepoints would fall back on traps, using uprobes could decrease the overhead on inserting/processing a trap instruction. Also the uprobes handler could be used to collect the information in the same process context. Alternatively gdb could use user_bkpt layer to insert traps and collect the information in the tracer's context. However this would require tracer to do some additional work. Still this should be provide lesser overhead than ptrace. Uprobes/user_bkpt implements execution out of line, hence it scales well with multithreaded applications. Also as Frank already pointed out, uprobes/utrace were designed for allowing multiple tracing sessions to connect to the same tracee. I am ignorant on how gdb dynamic tracepoints was implemented to comment on how gdb could further use uprobes/utrace. Can you please point me to some documentation on the same. -- Thanks and Regards Srikar