From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7593 invoked by alias); 19 Apr 2010 14:14:10 -0000 Received: (qmail 7573 invoked by uid 22791); 19 Apr 2010 14:14:08 -0000 X-SWARE-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Apr 2010 14:14:01 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o3JEDvkr018506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Apr 2010 10:13:57 -0400 Received: from fche.csb (vpn-237-154.phx2.redhat.com [10.3.237.154]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o3JEDu1U016927; Mon, 19 Apr 2010 10:13:57 -0400 Received: by fche.csb (Postfix, from userid 2569) id 3064358100; Mon, 19 Apr 2010 10:13:56 -0400 (EDT) Date: Mon, 19 Apr 2010 14:14:00 -0000 From: "Frank Ch. Eigler" To: Dominique Toupin Cc: gdb@sourceware.org, systemtap@sourceware.org Subject: Re: Static/dynamic userspace/kernel trace Message-ID: <20100419141356.GC4823@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i 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/msg00053.txt.bz2 Hi - On Mon, Apr 19, 2010 at 09:16:04AM -0400, Dominique Toupin wrote: > 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 > - 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? Recall that systemtap goes beyond just tracing with simple local conditions. There are dozens of nontrivial systemtap scripts that involve conditions based on history, searching through live data structures, taking actions, making state changes. The above technologies do not stretch that far, nor are they integrated. The main motivating dependence by systemtap on utrace has been due to uprobes. We shall see to what extent lkml is receptive to a utrace-free-uprobes implementation being worked on now. If it is merged and usable, this would moot one particular dependence. But there are other needs: proper process control facility like utrace enables scripted operations such as clean thread suspend/resume or signal generation/suppression. And of course utrace in general has ambitions beyond systemtap. As oft repeated on lkml etc., some sort of process control multiplexing facility is necessary so that a single ptrace-client tool does not monopolize target processes. That newfangled gdb tracing stuff does not work if someone was already strace'ing the same process. This is why we prototyped the gdbstub-in-kernel for userspace processes, based on utrace. It already demonstrated concurrent gdb+strace on the same threads. - FChE