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)
next prev parent 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).