public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: David Smith <dsmith@redhat.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: Systemtap List <systemtap@sources.redhat.com>
Subject: Re: BZ#2421 - removing duplicate probe handlers
Date: Thu, 03 Aug 2006 14:58:00 -0000	[thread overview]
Message-ID: <1154616973.32247.26.camel@dhcp-2.hsv.redhat.com> (raw)
In-Reply-To: <20060803015402.GB8671@redhat.com>

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)


  reply	other threads:[~2006-08-03 14:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1153430594.9668.57.camel@dhcp-2.hsv.redhat.com>
     [not found] ` <1153494928.11557.24.camel@dhcp-2.hsv.redhat.com>
2006-07-21 16:01   ` Frank Ch. Eigler
2006-07-21 19:15     ` David Smith
2006-08-01 18:39       ` David Smith
2006-08-01 22:49         ` Frank Ch. Eigler
2006-08-02 21:16           ` David Smith
2006-08-03  1:54             ` Frank Ch. Eigler
2006-08-03 14:58               ` David Smith [this message]
2006-08-08 19:28                 ` David Smith
2006-08-01 22:53         ` Frank Ch. Eigler
2006-08-02  8:03         ` Li Guanglei
2006-08-02 13:19           ` David Smith
2006-08-02 23:07 Stone, Joshua I
2006-08-03 14:24 ` David Smith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1154616973.32247.26.camel@dhcp-2.hsv.redhat.com \
    --to=dsmith@redhat.com \
    --cc=fche@redhat.com \
    --cc=systemtap@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).