This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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)



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]