Re: [Bug translator/2421] translator emitting duplicate probe handlers

[fche at redhat dot com (Frank Ch. Eigler)]

Hi -

With this code now in, it will be time for the next step of
duplication elimination.  I hope this will make it clear why I talked
dsmith out of the earlier amazing "48k" variant mentioned in
http://sourceware.org/ml/systemtap/2006-q3/msg00208.html.

The next idea is to extend the translator guts to group all probes
using the same lower level kernel API (kprobes / kretprobes / perfmon
/ any others) together.  Importantly, this grouping would *not* be
based on any similarity amongst probe handler bodies, only the probe
points!  The goal of this method is to give a new layer of translator
code the chance to emit a single combined registration,
unregistration, and callback function *for each group as a whole*.  (I
have some C++ implementation ideas on this for the person who wants to
undertake the work.)

Among other things, this sort of grouping is required for perfmon.
When/if the kprobes API allows mass registration/unregistration, this
will readily exploit it.  (It is a shame that the modules_get_byname()
code was boo'd by essentially one ignorant critic, since by
sorting/grouping all kprobes in the translator, we could most
efficiently perform the necessary relocation / locking and still
retain full generality.)

In any case, the result should be the elimination of even more
duplication compared to the "48k" variant.  It should approximate the
conceptual minimum amount of code required for the probe<->kernel
glue.  Finally, if it is still economical to do so, some effort may be
directed toward improving the code for ordinary
statements/expressions.  Then we will be "done".

- FChE