Re: Forw: function and source matching

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

roland wrote voluminously:

> The architecture paper in 3.1.1 says, "The function name may be suffixed by
> @filename or even @filename:lineno to identify a source-level scope within
> which the identifiers should be searched."  I think what you're saying is
> that you take the set of identifiers that, had they appeared in the source
> code at filename:lineno, would have named a function, and match your
> function name or name pattern against those.  

No.  I mean a natural source-centric search predicate, operating upon
all functions defined within (CUs of) the kernel or a module.  The
predicate would select those functions that match the given name
pattern, were defined in a file that matches the given pattern, and
that definition spanned the given line number (if given).

It is OK if for convoluted cases (e.g. function bodies partially
coming from headers), heuristics are applied to approach that idea.
It is OK if dwarf data limitations force heuristics or approximations.
It is OK if libelf does not provide an all-inclusive search
megafunction, as long as systemtap can perform iteration and predicate
evaluation on its own.


> [...For function selection] you seem to be using the same
> specification for function selection and then for specific PC
> lookup.  These are really separate things.  [...]

Of course they are: the predicate in this case is meant to select
statements (to be mapped to a specific, intra-function PC), not
functions (which would be mapped to the pre-prologue or post-prologue
address).  But the predicate operates on the same source-centric
co-ordinate system.  That is why the syntax is very similar.


- FChE