From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19259 invoked by alias); 17 May 2004 18:29:54 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 19250 invoked from network); 17 May 2004 18:29:52 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 17 May 2004 18:29:52 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i4HITqRm019046 for ; Mon, 17 May 2004 14:29:52 -0400 Received: from zenia.home.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i4HITo028626; Mon, 17 May 2004 14:29:51 -0400 To: Eli Zaretskii Cc: Alexandre Courbot , gdb@sources.redhat.com Subject: Re: Using gdb as a trace agent References: <40A8B71B.8030200@lifl.fr> <40A8ECB7.8000107@lifl.fr> <6654-Mon17May2004202803+0300-eliz@gnu.org> From: Jim Blandy Date: Mon, 17 May 2004 18:29:00 -0000 In-Reply-To: <6654-Mon17May2004202803+0300-eliz@gnu.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-05/txt/msg00105.txt.bz2 "Eli Zaretskii" writes: > > Date: Mon, 17 May 2004 18:47:51 +0200 > > From: Alexandre Courbot > > > > The ideal for me would be to be able to use tracepoints in both cases > > (i.e. remote and local). What would prevent a local support for tracepoints? > > Nothing, except the fact that the code to do that has not been > written yet. > > If you fill that void, you will have my eternal gratitude. > > > no chance to get tracepoints to work locally? That would turn GDB > > into a great analysis tool. > > This was discussed in the past, and everybody agreed it would be > great. Now all we need is someone to step forward and code that. Yep. Here's why it's only been implemented remotely: On a typical remote embedded system communicating with GDB via a stub, the stub is installed as a trap handler: when the debuggee hits a breakpoint, the processor simply transfers control to the stub. The stub then chats with GDB for as long as is necessary, and when it receives a 'continue' packet, it returns from the trap handler. This means that it's pretty easy to add tracepoints in a low-overhead way. The stub just looks up the address of the instruction at which the trap occurred in a table of tracepoints; if it finds a tracepoint at that address, it collects the associated data, and continues immediately. So for native configurations, the challenge is to find a low-overhead way to handle those traps. For example, one could add tracepoint support to gdbserver, but then you'd have one process collecting data from another process via ptrace or some other system call, and it wouldn't be very lightweight.