From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7034 invoked by alias); 18 May 2009 22:56:38 -0000 Received: (qmail 7026 invoked by uid 22791); 18 May 2009 22:56:38 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 18 May 2009 22:56:31 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n4IMs6pw015357; Mon, 18 May 2009 18:54:06 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n4IMs5gM015979; Mon, 18 May 2009 18:54:05 -0400 Received: from opsy.redhat.com (vpn-12-127.rdu.redhat.com [10.11.12.127]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n4IMs4cg011679; Mon, 18 May 2009 18:54:04 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id B5E5B3784BC; Mon, 18 May 2009 16:54:03 -0600 (MDT) To: Stan Shebs Cc: Tristan Gingold , gdb-patches@sourceware.org Subject: Re: RFA: makes darwin-nat.c threads (and multi-processes) aware References: <20090319141746.GA81236@ulanbator.act-europe.fr> <4A11BE08.3090900@codesourcery.com> From: Tom Tromey Reply-To: tromey@redhat.com Date: Mon, 18 May 2009 22:56:00 -0000 In-Reply-To: <4A11BE08.3090900@codesourcery.com> (Stan Shebs's message of "Mon\, 18 May 2009 12\:59\:04 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-05/txt/msg00378.txt.bz2 >>>>> "Stan" == Stan Shebs writes: Stan> Seeing all the inferior_debug calls with different args, while I'm Stan> working on fixing up tracepoints, gets me to thinking about whether we Stan> can use tracepoints instead of ever-more debug printfs in GDB (looks Stan> bad when the chefs in the kitchen send next door for takeout :-) ), Stan> but that's a subject of its own... I have wondered about this myself -- not using tracepoints, exactly, but a new command implemented in Python that is basically a combination of "break" and "printf" with an implicit "cont". The problem I didn't know how to solve was naming the locations of the debugging prints such that the location remains meaningful when the source changes. Function names work pretty well, of course, but they are also limited when you have a very large function. Systemtap and dtrace solve this by having users annotate their code; the annotations turn into code that is disabled until the trace is in effect. We could hook into these from gdb; and then annotate gdb with them. If we wanted. Tom