Re: systemtap markers and gdb

[Tom Tromey <tromey@redhat.com>]

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