This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: BZ#2421 - removing duplicate probe handlers
- From: David Smith <dsmith at redhat dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: Systemtap List <systemtap at sources dot redhat dot com>
- Date: Fri, 21 Jul 2006 14:13:25 -0500
- Subject: Re: BZ#2421 - removing duplicate probe handlers
- References: <1153430594.9668.57.camel@dhcp-2.hsv.redhat.com> <1153494928.11557.24.camel@dhcp-2.hsv.redhat.com> <20060721160146.GB4437@redhat.com>
On Fri, 2006-07-21 at 12:01 -0400, Frank Ch. Eigler wrote:
> Hi -
>
> > > I've been looking into BZ#2421 this week while waiting for people to
> > > look at the kernel patch. [...]
>
> OK.
...
> > [...] So, should function duplication removal work globally or only
> > per probe specification line?
>
> I imagine it working globally. I believe what we need is a variant of
> the compiler optimization known as "value numbering". It could live
> in a new optimization pass within semantic_pass_optimize. It could
> compute a hash value for every function & probe-handler from the
> bottom up (requiring a new staptree-related visitor, and include
> referent-names and parse tree types). Multiple functions &
> probe-handlers with the same hash value could be duplicate-eliminated.
> (In the case of functions, all the callers of one of the duplicates
> would be redirected to a single one. In the case of probe handlers,
> their probe_location would be merged.) (With the addition of a
> parse-tree-comparison visitor, one could eliminate the slight risk of
> a hash collision.)
(Wow. I've got to learn to stop asking Frank what seem to me to be
simple questions - I always seem to end up with lots more work...)
> This should supplant the target-variable flavouring magic for dwarf
> probes.
Hmm. Would it make sense to keep the current flavouring magic as a sort
of "pass 1" attack at removing duplicate probe handlers?
> Does this make sense? It's a little more ambitious, but want to give
> it a try?
>
> - FChE
It makes since in a vague sort of way. I'll give it a try and look into
it.
--
David Smith
dsmith@redhat.com
Red Hat, Inc.
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)