From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5296 invoked by alias); 13 Jan 2011 16:06:59 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 5280 invoked by uid 22791); 13 Jan 2011 16:06:57 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org From: Tom Tromey To: pmuldoon@redhat.com Cc: Project Archer Subject: Re: systemtap markers and gdb References: Date: Thu, 13 Jan 2011 16:06:00 -0000 In-Reply-To: (Phil Muldoon's message of "Thu, 13 Jan 2011 15:53:25 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2011-q1/txt/msg00013.txt.bz2 Phil> Why the catch syntax, and not just an addition to the linespec code so Phil> that we can just set regular breakpoints on them? It would be neat then Phil> to interface with the upcoming condition/action python code. We considered this but decided on catchpoints for two reasons. First, we wanted to expose the marker arguments somehow. Adding special behavior to breakpoints for one kind of linespec seemed ugly. Second, linespec.c is already too gross. It occurs to me now that I don't know how we'll support letting the user view the marker arguments outside of "commands". Maybe instead of a special convenience function we should just set a bunch of convenience variables, or a single array-valued convenience variable. Phil> (Though I guess in mediation, though we have no catchpoint support in Phil> the Python API at present, there is no reason that we cannot at some Phil> point). Yeah, we will want to do that as part of this work. Tom