BZ#2421 - removing duplicate probe handlers

[Frank Ch. Eigler]

Hi -

> > I've been looking into BZ#2421 this week while waiting for people to
> > look at the kernel patch.  [...]

OK.

> - Variable lifetimes.  The probe_flavours list down in
> dwarf_query::add_probe_point() is now global, but the dps list in
> semantic_pass_symbols() is now per file.

Global as in "global scope"?  We should avoid that kind of stuff in
C++, and instead add members to something like systemtap_session.

> Do you remember exactly what is a "file" in the context of
> semantic_pass_symbols()?  Is that a tapset file or something else?

It's a "struct stapfile*" - one parse tree for an entire file.  One of
these would be the input script, and many would be the ton of tapset
scripts.

> - Current flavour code needs to be improved.  [...]

Yeah.

> [...] 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.)

This should supplant the target-variable flavouring magic for dwarf
probes.

Does this make sense?  It's a little more ambitious, but want to give
it a try?

- FChE