From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12654 invoked by alias); 19 Apr 2010 19:50:28 -0000 Received: (qmail 12628 invoked by uid 22791); 19 Apr 2010 19:50:26 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from imr1.ericy.com (HELO imr1.ericy.com) (198.24.6.9) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Apr 2010 19:50:20 +0000 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o3JJsbid019817; Mon, 19 Apr 2010 14:54:37 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.197]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 19 Apr 2010 15:50:02 -0400 From: Dominique Toupin To: "Frank Ch. Eigler" CC: "gdb@sourceware.org" , "systemtap@sourceware.org" Date: Mon, 19 Apr 2010 19:50:00 -0000 Subject: RE: Static/dynamic userspace/kernel trace Message-ID: References: <20100419141356.GC4823@redhat.com> In-Reply-To: <20100419141356.GC4823@redhat.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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/msg00060.txt.bz2 I agree that GDB could use a better ptrace. Regarding tracing, for me the main use case is to get the data out of the s= ystem very fast and with very low overhead, besides conditional tracing and= a few minor things, most of the analysis is done on the host side, either = after the fact or in streaming mode. Doing historical analysis on the targe= t or big actions are not an option for me. I guess in the IT industry more = cycles are available to do those kinds of analysis directly on the target s= erver. > -----Original Message----- > From: Frank Ch. Eigler [mailto:fche@redhat.com]=20 > Sent: 19-Apr-10 10:14 > To: Dominique Toupin > Cc: gdb@sourceware.org; systemtap@sourceware.org > Subject: Re: Static/dynamic userspace/kernel trace >=20 > Hi - >=20 > On Mon, Apr 19, 2010 at 09:16:04AM -0400, Dominique Toupin wrote: >=20 > > I had a chat with Tom at the collaboration summit on=20 > tracing, he was=20 > > suggesting I send you a mail on a recent GDB improvement.=20=20 > You might=20 > > not be aware that user space dynamic tracepoint are now=20 > available in=20 > > GDB, in process tracing if a few byte space is available to put a=20 > > jump, if that space is not available then a trap between=20 > gdbserver and=20 > > the process. With this addition all aspects of tracing seem to be=20 > > covered: > > > > - static user space: LTTng UST > > - dynamic user space: GDB dynamic tracepoint > > - static kernel: kernel static tracepoint/trace event > > - dynamic kernel: kprobe > > > > and conditional tracing is available for both kernel and user space. >=20 > All right. >=20 >=20 > > Tom was saying uprobes/utrace can bring nice improvements=20 > for ptrace,=20 > > for tracing it was not clear to me or Tom why we need=20 > uprobe/utrace or=20 > > why systemtap needs it. Do you have a use case where the=20 > above tracing=20 > > cannot be use and uprobe/utrace is needed instead? >=20 > Recall that systemtap goes beyond just tracing with simple=20 > local conditions. There are dozens of nontrivial systemtap=20 > scripts that involve conditions based on history, searching=20 > through live data structures, taking actions, making state=20 > changes. The above technologies do not stretch that far, nor=20 > are they integrated. >=20 > The main motivating dependence by systemtap on utrace has=20 > been due to uprobes. We shall see to what extent lkml is=20 > receptive to a utrace-free-uprobes implementation being=20 > worked on now. If it is merged and usable, this would moot=20 > one particular dependence. But there are other needs: proper=20 > process control facility like utrace enables scripted=20 > operations such as clean thread suspend/resume or signal=20 > generation/suppression. >=20 > And of course utrace in general has ambitions beyond=20 > systemtap. As oft repeated on lkml etc., some sort of=20 > process control multiplexing facility is necessary so that a=20 > single ptrace-client tool does not monopolize target=20 > processes. That newfangled gdb tracing stuff does not work=20 > if someone was already strace'ing the same process. This is=20 > why we prototyped the gdbstub-in-kernel for userspace=20 > processes, based on utrace. It already demonstrated=20 > concurrent gdb+strace on the same threads. >=20 >=20 > - FChE >=20