From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13302 invoked by alias); 13 Jan 2011 17:15:33 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 13284 invoked by uid 22791); 13 Jan 2011 17:15:30 -0000 X-SWARE-Spam-Status: No, hits=-4.6 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 Thursday, 13 January 2011 09:06:50 -0700 References: Message-Id: <20110113171524.143B7403EB@magilla.sf.frob.com> Date: Thu, 13 Jan 2011 17:15:00 -0000 X-SW-Source: 2011-q1/txt/msg00014.txt.bz2 There are three flavors of encoding from various different versions of systemtap. The nicest one is the most recent (aka v3), which is only available in the forthcoming systemtap 1.4. Are you supporting more than one flavor, or only the latest flavor? (I think it's fine to support only this latest flavor.) It's not clear if 'info markers' tells you what object the markers are in. I notice that there is no way to specify a constraint on which objects you want 'info markers' or 'catch marker' to match. In contrast, in the systemtap syntax you always say which objects you want to look for a particular marker in. It's probably most common that a given provider name is only used in a single object. But it doesn't have to be so. In particular, a library might provide markers in its inlines and then those would appear under the library's choice of provider name, but in the various objects that inlined its calls or methods. I suppose it's consistent with the rest of gdb's breakpoint selection that you don't explicitly say which objects you are talking about, but I thought I'd mention the issue. > 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. Given that the probe arguments are only positional (have no names), an array makes the most sense at first blush. OTOH, in the latest sdt.h flavor, there is some nominal degree of type information on the arguments. I presume an array-valued convenience variable would have to convert them all to a single type and hence lose that information (though perhaps do signedness-aware conversion and so not lose anything that really matters). Today, the type information consists of signedness and size (1,2,4,8) and all arguments are integers (including pointers treated as uintptr_t). But it's possible that in the future the format will be extended to describe FP types too, or be richer in other ways. So you probably don't want to expose a gdb interface now that would need to be changed later for richer argument types. Thanks, Roland