This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Forw: function and source matching


From: Roland McGrath <roland@redhat.com>
Date: Thu, 11 Aug 2005 03:01:19 -0700 (PDT)

I'd like to clarify some details of the systemtap syntax features for
selecting things by source location and function names.  I'm helping
Graydon make sense of what questions DWARF should answer to implement what
you want, and it has become unclear exactly which things you are asking for.

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.  If you omit :lineno, then
what does @filename alone mean?  Does it mean look at the set of function
names visible from file scope in filename?  Does it mean look at the union
of the sets of function names visible from all places in filename?  Graydon
has been talking about using fnmatch on the file names as well, which is
not mentioned in the paper.

The "had they appeared in the source code at filename:lineno" is actually
easier said than done.  DWARF is structured such that there is an
association of PC addresses with line numbers that is independent of the
DWARF entries about things like functions.  Then there are DWARF entries
describing lexical scopes and things in them; the scopes that are part of
functions are associated with sets of PC locations.  So when there is some
code associated with the source location you are interested in, then you
can find the binding scope that says what names are visible from there.
Additionally, every name's definition or declaration is associated with the
source location of that declaration.  There is no lexical scope for "source
file".  There is compilation unit, which is the top-level scope DWARF
represents.  It is the granularity of a top-level file after all #include
processing, corresponding to some number of source files.  What in C is
called "file scope" is compilation unit scope; "global" actually just means
compilation-unit scope declarations marked external.  There is a top-level
file name associated with each CU, and each CU has a set of source files
that have PC locations and/or declarations associated with them.  So, you
can choose CUs by matching on any or all of these names if you like.  (If
you are matching without regard to line number, then this is exactly
equivalent to finding PC values with source locations in those files and
then looking at the CU scope containing that PC.)

When you look for a function without constraint of source location, do you
want to look at names in CU scope, i.e. global and file-scope static functions?
Or all functions at any scope?

It's not clear to me which of these things you want to check, and in which
order.  Frank mentioned something like "an algorithm describing what gdb
does", and I have no idea what that might refer to.  gdb supports exactly
two things: a PC located by exact match on a filename and >= match on
linenumber; the entry PC of a CU-scope function located by exact name
match.  These are what the convenience functions in libdw make easy already
(dwarf_getsrc_files, dwarf_getfuncs).  If you want fancier things, I'd like
to make those easier as well, but I need a clearer idea on what precisely
you want.

Section 3.1.2 says a statement probe is specified "much like a function
probe".  The interpretations of source information I described above relate
to what it means for function selection.  Here you seem to be using the
same specification for function selection and then for specific PC lookup.
These are really separate things.  You may need to cite func@foobar.c to
indicate which function you mean, but then the source location within that
function that you want is in foobar_subfile.c because of #include use.
Obviously in most cases the ambiguity won't come up.  But keeping the
general case in mind, I think the way to structure this is as function
selection, which yields a set of PCs associated with the chosen function
(or set of sets for func*, take their union), and then source location
matching within that PC set.  



Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]