Re: [PATCH 3/6] Modify internalvar mechanism

[Tom Tromey <tromey@redhat.com>]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Pedro> Do I understand correctly that this still creates
Pedro> a regular trap tracepoint at the probe location?
Pedro> A fast tracepoint ("ftrace") at that spec would
Pedro> create a fast tracepoint at the probe's location, and 
Pedro> things would magically work, because $_probe_argN is just
Pedro> sugar for collecting memory and registers, right?

I believe it should all work, but I did not think to try fast
tracepoints.  I don't know whether Sergio did.

Yes, the probe arguments are just a wrapper around some kind of
assembly-level operand.  These are known statically to gdb; the operands
are encoded as strings in the appropriate section.  A good part of the
main patch is devoted to parsing these.

It might be nice if we had a way to print the operand strings.  This
isn't always useful, but maybe we could add some optional flag to "info
probe".  Or, maybe just another flag to readelf.

Pedro> I noticed that patch 4 does some changes to 
Pedro> start_tracing to tweak the probes' semaphores, if any.
Pedro> What are these semaphores?  How do other stap tools
Pedro> handle them?  I ask because that bends a bit the definition
Pedro> of "trace" being a regular tracepoint at a given
Pedro> location, so I'd like to understand it.

A probe can optionally have an associated "semaphore".  A semaphore in
the sdt.h sense is just a global variable (of type unsigned short) which
can be used to gate the probe.  Typically these are only generated by
code using the dtrace compatibility wrappers.

Without a semaphore a probe may look like:

  STAB_PROBE (provider, name, arg);

But with a semaphore it would more typically be written (though I think
in practice there may be macros expanding to the semaphore name):

  if (provider_name_semaphore)
    STAB_PROBE (provider, name, arg);

Aside from providing some source compatibility with dtrace probes, this
can also be used in a situation where computing the probe arguments is
expensive.  In Fedora 15, at least Python takes this approach.  But,
OTOH, libgcc and glibc do not.

The only other tool I know of that deals with these probe points is
SystemTap.  It treats the semaphore as a counter.  I don't know the
specifics, but basically it is incremented by stap at "attach" and
decremented at "detach".  We made gdb work the same way, for
compatibility.  (I have not done it but I believe it is possible to use
stap and gdb to probe the same process at the same time.)

So, since setting the semaphore is necessary to make the probe even
trigger, it seemed to make sense to have gdb set it, and to leave it set
during the trace experiment.  One reason we decided to make `probe:'
linespecs special with regard to semaphores is because it makes it clear
that the user has asked for some additional behavioral change on top of
the breakpoint.  (We could alternatively have made `break *0xaddress'
magically work at a probe point, the way we did for probe arguments...)

Tom