From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28303 invoked by alias); 4 Feb 2011 23:45:24 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 28294 invoked by uid 22791); 4 Feb 2011 23:45:23 -0000 X-SWARE-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Tom Tromey Cc: Project Archer Subject: Re: systemtap markers and gdb In-Reply-To: Tom Tromey's message of Friday, 4 February 2011 15:00:21 -0700 References: <20110113171524.143B7403EB@magilla.sf.frob.com> Message-Id: <20110204234515.1A0071801CF@magilla.sf.frob.com> Date: Fri, 04 Feb 2011 23:45:00 -0000 X-SW-Source: 2011-q1/txt/msg00030.txt.bz2 As a (potential) user, that sounds reasonable to me. The other cool feature that would follow naturally from a user perspective is an automagic display of a probe and its arguments at a probepoint. That would be something that looks a bit like a frame display, e.g.: #0 probe providername:probename ($arg1=123, $arg2=456) Possibly this could be a "virtual frame" sort of thing, but most likely people don't want it to obscure the actual frame that contains the probe. It's more useful if it's just extra information displayed at the same times you would display frame info (at a stop, at up/down/frame commands, etc.) when the frame PC has a probe there. Since a probe site is an extra nop instruction where the breakpoint goes, it might actually be useful to display this at the instruction immediately before it or immediately after it, or even on the source lines containing the instructions right around it. Or maybe something even fuzzier, where it might not be able to show the probe argument values, e.g., if the probe precedes or follows a call, then having "up" et al display what probe site is right there could be nice, even if the probe arguments are clobbered by the call, or are dependent on the call's return value. Those ideas are all extra gravy after direct support at the probe site PC itself, of course. > First, a new linespec that looks like `marker:[OBJFILE]:PROVIDER:NAME'. I assume that is actually `marker:[OBJFILE:]PROVIDER:NAME'. Note that in the stap syntaxes, specifying the PROVIDER part is also optional, since some probe names are quite distinctive already. So perhaps it should really be `marker:[OBJFILE:][PROVIDER:]NAME'. (And personally I would go with "probe" rather than "marker", since the macros to create them are called *_PROBE. OTOH, the stap syntax is `[.provider("NAME")].mark("NAME")'. Also note that in stap syntax, each NAME is actually a glob pattern.) > E.g.: (gdb) break marker:glibc:pthread_create BTW, as currently proposed, the provider names for the glibc static probes will be the library basename, i.e. libc or libpthread. > 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. I'd prefer slightly less verbose names for the variables, but it's not a significant issue. Thanks, Roland