From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30058 invoked by alias); 13 Jan 2011 17:38:39 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 29683 invoked by uid 22791); 13 Jan 2011 17:38:36 -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: Thu, 13 Jan 2011 17:38:00 -0000 In-Reply-To: <20110113171524.143B7403EB@magilla.sf.frob.com> (Roland McGrath's message of "Thu, 13 Jan 2011 09:15:24 -0800 (PST)") 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/msg00015.txt.bz2 Roland> There are three flavors of encoding from various different versions of Roland> systemtap. The nicest one is the most recent (aka v3), which is only Roland> available in the forthcoming systemtap 1.4. Are you supporting more Roland> than one flavor, or only the latest flavor? (I think it's fine to Roland> support only this latest flavor.) We are planning to only support the latest flavor. Also, FWIW, we weren't planning to integrate this with the existing GDB marker support. That code only works for tracepoints and requires the inferior to use UST. I think we could do this integration, but my impression is that right now we don't have many users using tracepoints -- whereas we have some immediate uses for these catchpoints. Roland> In contrast, in the systemtap syntax you always say which objects you Roland> want to look for a particular marker in. It's probably most common that Roland> a given provider name is only used in a single object. But it doesn't Roland> have to be so. In particular, a library might provide markers in its Roland> inlines and then those would appear under the library's choice of Roland> provider name, but in the various objects that inlined its calls or Roland> methods. I suppose it's consistent with the rest of gdb's breakpoint Roland> selection that you don't explicitly say which objects you are talking Roland> about, but I thought I'd mention the issue. Thanks. I will add an option argument to allow this kind of selection, like: catch marker [objfile] provider name info markers [objfile] [provider [name]] Tom> It occurs to me now that I don't know how we'll support letting the user Tom> view the marker arguments outside of "commands". Maybe instead of a Tom> special convenience function we should just set a bunch of convenience Tom> variables, or a single array-valued convenience variable. Roland> Given that the probe arguments are only positional (have no names), an Roland> array makes the most sense at first blush. OTOH, in the latest sdt.h Roland> flavor, there is some nominal degree of type information on the Roland> arguments. I presume an array-valued convenience variable would have to Roland> convert them all to a single type and hence lose that information Roland> (though perhaps do signedness-aware conversion and so not lose anything Roland> that really matters). Yeah, they would have to all be the same size. Roland> Today, the type information consists of signedness and size (1,2,4,8) Roland> and all arguments are integers (including pointers treated as Roland> uintptr_t). But it's possible that in the future the format will be Roland> extended to describe FP types too, or be richer in other ways. So you Roland> probably don't want to expose a gdb interface now that would need to be Roland> changed later for richer argument types. Thanks. We can either just go with multiple convenience variables ($_marker_arg0, $_marker_arg1, etc) or a phony struct. I lean toward the former since it is simpler and since that is how `define' already works. Tom