From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19272 invoked by alias); 4 Feb 2011 22:00:30 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 19261 invoked by uid 22791); 4 Feb 2011 22:00:29 -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: Roland McGrath Cc: Project Archer Subject: Re: systemtap markers and gdb References: <20110113171524.143B7403EB@magilla.sf.frob.com> Date: Fri, 04 Feb 2011 22:00:00 -0000 In-Reply-To: (Tom Tromey's message of "Thu, 13 Jan 2011 10:38:25 -0700") 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/msg00029.txt.bz2 Tom> Also, FWIW, we weren't planning to integrate this with the existing GDB Tom> marker support. That code only works for tracepoints and requires the Tom> inferior to use UST. I think we could do this integration, but my Tom> impression is that right now we don't have many users using tracepoints Tom> -- whereas we have some immediate uses for these catchpoints. We were discussing this again on irc yesterday, and Roland had an intriguing idea about how to handle marker arguments. The main motivation for implementing marker support using a catchpoint rather than a breakpoint with a new kind of linespec was that we want to expose the marker arguments to scripts, but we didn't want to make this dependent on the kind of linespec in use. Roland's idea is to make this PC-based -- make the marker arguments available at a marked PC, regardless of how one ended up at that PC. So, I think we should change our plans back. This means rewriting the UI code on the branch, which I will do. Using linespecs has a few nice features. First, it doesn't require any more Python API, it will all just work. Ditto for the internal places where we want to use stap markers (exceptions, longjmp). Also, it seems very easy to make marker arguments work with tracepoints. I also looked at the exist UST-based static tracepoint markers, to see if we could or should share anything. >From what I can tell, the UST work defines two additional commands: the static tracepoint command ("strace" -- sigh) and "info static-tracepoint-markers". We won't need "strace", since our approach is more general. "info static-tracepoint-markers" is like our "info markers", but it includes some columns that are not relevant, and it doesn't seem to have the notion that a given marker may resolve to more than one address. So, while maybe we could use the same command, but I think in the first patch we will not. It isn't a perfect fit and its name makes it tracepoint-specific besides. I didn't rewrite the docs yet, but here is the new proposal. First, a new linespec that looks like `marker:[OBJFILE]:PROVIDER:NAME'. E.g.: (gdb) break marker:glibc:pthread_create I'll try to make this a bit generic so we could stick in new kinds of linespec prefixes later. Second, a bunch of convenience variables, $marker_argc, $marker_arg0 .. $marker_arg9. These will always be visible, but will throw exceptions unless the current PC is a marker PC. These will include a method to compile the reference to the AX bytecode. Third, a new "info markers" command, as in the earlier proposal. Let me know what you think. Tom