Re: [PATCH 3/6] Modify internalvar mechanism

[Pedro Alves <pedro at codesourcery dot com>]

On Tuesday 12 April 2011 23:33:05, Sergio Durigan Junior wrote:
> Pedro Alves <pedro@codesourcery.com> writes:
> 
> > On Monday 04 April 2011 04:08:34, Sergio Durigan Junior wrote:
> >> Hi,
> >> 
> >> This patch modifies the mechanism of internalvar.  It basically adds
> >> more manipulation functions to them (`compile_to_ax' and `destroy'), and
> >> updates the definitions and pointers of existing internalvars.
> >
> > Can you explain this?  Why would you want to compile an internal var
> > to AX, for example?
> 
> A SystemTap probe can have up to 10 arguments.  In our original plan,
> the idea is that the user should be able to collect those arguments
> using the tracepoint mechanism.  Since we already have the necessary
> code to evaluate an argument (which is treated as an internal varibale
> inside GDB), we thought it would be easier to extend this code in order
> to compile it to AX.
> 
> You could do something like:
> 
>     (gdb) trace probe:test
>     ..
>     (gdb) actions
>     ..
>     > collect $_probe_arg0
>     > end
>     ..

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

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

> In order to collect the probe's first argument, and so on.

I see.  Sounds like a good approach.

(I'm reading patch 4 piecemeal, but it's taking a
bit to grok it all).

-- 
Pedro Alves