This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH 3/6] Modify internalvar mechanism
On Tuesday 12 April 2011 23:33:05, Sergio Durigan Junior wrote:
> Pedro Alves <email@example.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).