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]

Re: stap error: no match while resolving probe point kernel.function("do_mmap_pgoff@mm/mmap.c:901")


2010/2/22 PrzemysÅaw PaweÅczyk <przemyslaw@pawelczyk.it>:
> Not all local variables are accessible in stap scripts. It depends on
> many things:
> - what compiler really does with them,
> - how good debuginfo compiler generates,
> - is elfutils able to fully (and correctly) recognize this debuginfo,
> - maybe even something more I don't remember now.

The consequence of the first point is that it depends also on a probe
location, i.e. some variables are available only in specific parts of
functions.

> OTOH you obviously aren't interested in the initial value of the
> variable, which is already known, so e.g.
> 'kernel.function("do_mmap_pgoff@mm/mmap.c+205")' would be more
> interesting assuming correct_wcount availability.

I (and you before) made a mistake using kernel.function for
line-oriented probing. Mark has already posted an explanation.

On Mon, Feb 22, 2010 at 13:13, Mark Wielaard <mjw@redhat.com> wrote:
> If you need to try at a specific line, instead of at the function start,
> then you might also try a kernel.statement probe instead of a
> kernel.function probe.

Therefore there is a hope that:

stap -L 'kernel.statement("do_mmap_pgoff@mm/mmap.c+205")'

will show you correct_wcount.

Regards.

-- 
PrzemysÅaw PaweÅczyk


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