Re: systemtap markers and gdb

[Tom Tromey <tromey@redhat.com>]

Tom> Also, FWIW, we weren't planning to integrate this with the existing GDB
Tom> marker support.  That code only works for tracepoints and requires the
Tom> inferior to use UST.  I think we could do this integration, but my
Tom> impression is that right now we don't have many users using tracepoints
Tom> -- whereas we have some immediate uses for these catchpoints.

We were discussing this again on irc yesterday, and Roland had an
intriguing idea about how to handle marker arguments.

The main motivation for implementing marker support using a catchpoint
rather than a breakpoint with a new kind of linespec was that we want to
expose the marker arguments to scripts, but we didn't want to make this
dependent on the kind of linespec in use.

Roland's idea is to make this PC-based -- make the marker arguments
available at a marked PC, regardless of how one ended up at that PC.

So, I think we should change our plans back.  This means rewriting the
UI code on the branch, which I will do.

Using linespecs has a few nice features.  First, it doesn't require any
more Python API, it will all just work.  Ditto for the internal places
where we want to use stap markers (exceptions, longjmp).  Also, it seems
very easy to make marker arguments work with tracepoints.


I also looked at the exist UST-based static tracepoint markers, to see
if we could or should share anything.

From what I can tell, the UST work defines two additional commands: the
static tracepoint command ("strace" -- sigh) and "info
static-tracepoint-markers".

We won't need "strace", since our approach is more general.

"info static-tracepoint-markers" is like our "info markers", but it
includes some columns that are not relevant, and it doesn't seem to have
the notion that a given marker may resolve to more than one address.
So, while maybe we could use the same command, but I think in the first
patch we will not.  It isn't a perfect fit and its name makes it
tracepoint-specific besides.


I didn't rewrite the docs yet, but here is the new proposal.

First, a new linespec that looks like `marker:[OBJFILE]:PROVIDER:NAME'.
E.g.:  (gdb) break marker:glibc:pthread_create

I'll try to make this a bit generic so we could stick in new kinds of
linespec prefixes later.

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.

Third, a new "info markers" command, as in the earlier proposal.


Let me know what you think.

Tom