From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1919 invoked by alias); 21 Feb 2008 19:46:17 -0000 Received: (qmail 1910 invoked by uid 22791); 21 Feb 2008 19:46:16 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 21 Feb 2008 19:45:54 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 698073BE42; Thu, 21 Feb 2008 11:45:52 -0800 (PST) Subject: Re: gdbserver tracepoint support (from Project Ideas page) From: Michael Snyder To: Doug Evans Cc: gdb@sourceware.org In-Reply-To: References: <1203552043.19253.186.camel@localhost.localdomain> <1203555989.19253.190.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 21 Feb 2008 20:59:00 -0000 Message-Id: <1203623152.19253.193.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) Content-Transfer-Encoding: 7bit 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/msg00172.txt.bz2 On Wed, 2008-02-20 at 17:35 -0800, Doug Evans wrote: > 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 always thought that one interesting implementation for tracepoint data collection would be as a shared library that the child program could be linked with at runtime -- in the manner of libsegfault, so that you don't have to change the child program at all. In that way, it would share address space and only incur the cost of a signal handler, not a full context switch (or even a thread context switch). Is that something like your thinking?