Re: systemtap markers and gdb

[Roland McGrath <roland at redhat dot com>]

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