Re: systemtap markers and gdb

[Roland McGrath <roland@redhat.com>]

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