This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: BZ#2421 - removing duplicate probe handlers
On Wed, 2006-08-02 at 21:54 -0400, Frank Ch. Eigler wrote:
> Hi -
>
> > I tried to think through this a bit, and I believe I was thinking
> > too hard about this. [...] In addition, I realized that there are
> > cases where we don't want to merge probes even if they are identical
> > (but we could use your idea above of reusing the code bodies).
> > [...]
>
> As Josh said, merging should be a script-invisible phenomenon, and so
> must preserve semantics.
See my reply to Josh for the long answer to this, but the short version
is semantics should be preserved - I was wrong in my begin probe
example.
> Merging at the probe / derived_probe level
> *could* involve moving probe_location values from place to place. But
> now that I think about it more, it seems like a good place for both
> function and probe merging is in translate.cxx, strictly within the
> emit_{probe,function} routines.
I'll look into it.
> By the way, I was probably misunderstood with respect to hashing.
> What we need for duplicate detection is a way of equality-comparing
> two parse trees. If the staptree::print function is deemed reliable
> (and it may be a big if), then simple string comparison is good enough
> - i.e., use strings as keys for the duplicate detection table. There
> is no need to manually hash the strings! I mentioned hashing because
> I didn't consider the pretty-printing functions, so an identity hash
> number of a parse tree could instead be recursively built up from the
> bottom.
>
> - FChE
Oh, the current hash stuff was just a place holder. I realize I'm
basically doing a strcmp on function and probe bodies.
The current method will work (and could be replaced with a strcmp). The
additional benefit of an identity hash would be that it would work in
the case where 2 functions or probes are exactly the same, except for
the name of a variable.
--
David Smith
dsmith@redhat.com
Red Hat, Inc.
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)