From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14221 invoked by alias); 21 Feb 2008 01:36:24 -0000 Received: (qmail 14213 invoked by uid 22791); 21 Feb 2008 01:36:23 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 21 Feb 2008 01:36:06 +0000 Received: from zps76.corp.google.com (zps76.corp.google.com [172.25.146.76]) by smtp-out.google.com with ESMTP id m1L1ZwRw001152 for ; Thu, 21 Feb 2008 01:35:59 GMT Received: from rv-out-0910.google.com (rvbf5.prod.google.com [10.140.82.5]) by zps76.corp.google.com with ESMTP id m1L1Zkp8025059 for ; Wed, 20 Feb 2008 17:35:58 -0800 Received: by rv-out-0910.google.com with SMTP id f5so2437969rvb.59 for ; Wed, 20 Feb 2008 17:35:58 -0800 (PST) Received: by 10.141.202.12 with SMTP id e12mr6260622rvq.65.1203557758176; Wed, 20 Feb 2008 17:35:58 -0800 (PST) Received: by 10.141.142.4 with HTTP; Wed, 20 Feb 2008 17:35:58 -0800 (PST) Message-ID: Date: Thu, 21 Feb 2008 01:42:00 -0000 From: "Doug Evans" To: "Michael Snyder" Subject: Re: gdbserver tracepoint support (from Project Ideas page) Cc: gdb@sourceware.org In-Reply-To: <1203555989.19253.190.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1203552043.19253.186.camel@localhost.localdomain> <1203555989.19253.190.camel@localhost.localdomain> X-IsSubscribed: yes 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: 2008-02/txt/msg00162.txt.bz2 On Wed, Feb 20, 2008 at 5:06 PM, Michael Snyder wrote: > When you say "[not] much benefit to implementing tracepoints > natively", do you mean "as opposed to just using gdbserver > or equivalent"? Not precisely. To be honest I was hedging my bets because I've kinda thought tracepoints would find more use too, and given that there isn't yet support in gdbserver or native, I was wondering if there was a sufficient reason for not doing it that I was overlooking. Part of the initial reason for implementing them was to avoid transmitting packets back and forth at each tracepoint. That reason doesn't really apply to a native implementation but the process switching to implement this in ptrace (for linux) is a non-trivial intrusion for many apps (as it will be in gdbserver too), so maybe that's why it hasn't been implemented. A hybrid approach would be way cool (i.e. instrumenting the target program so tracepoints didn't stop the program even when running natively - this is where remote targets have an advantage, the stub is already in the same address space and process - but that ups the complexity a wee bit). > I've given thought to the issue, and I think Jim Blandy has > as well. Not enough thought to make a very complete picture... > > I think it would be useful, but then, I've always thought > tracepoints would find more use than they seem to have in > practice... > > > >