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

[Przemysław Pawełczyk]

On Mon, Feb 22, 2010 at 04:27, a qi <free4machine@gmail.com> wrote:
>  ./t15.stp  --vp 01
> semantic error: libdw failure (dwarf_getsrc_file): no matching address range
> semantic error: no match while resolving probe point
> kernel.function("do_mmap_pgoff@mm/mmap.c:901")
> semantic error: no probes found
> Pass 2: analyzed script: 0 probe(s), 0 function(s), 0 embed(s), 0
> global(s) in 140usr/80sys/219real ms.
> Pass 2: analysis failed.  Try again with another '--vp 01' option.
>
[snip]
>
> # t15.stp
> probe kernel.function("do_mmap_pgoff@mm/mmap.c:901"){
>         printf("the correct_wcount is : %d\n ",$correct_wcount)
> }

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.

'stap -L' shows which local variables you can use.

On my custom 2.6.32.3 built with gcc (Debian 4.3.2-1.1) 4.3.2, recent
stap built with recent elfutils (version 1.1/0.144 commit
release-1.1-98-gdac77b8), I have:
$ stap -L 'kernel.function("do_mmap_pgoff@mm/mmap.c")'
kernel.function("do_mmap_pgoff@mm/mmap.c:912") $file:struct file*
$addr:long unsigned int $len:long unsigned int $prot:long unsigned int
$flags:long unsigned int $pgoff:long unsigned int $mm:struct
mm_struct*
so only 1 of 5 local variables (mm, inode, vm_flags, error, reqprot) is here.

AFAIK not yet released gcc 4.5 gives much better debuginfo. But I'm
not sure whether using it would help you here. Other wise people (here
at ML but in different timezones) can elaborate this for sure.

> unsigned long do_mmap_pgoff(struct file * file, unsigned long addr,
>  883                        unsigned long len, unsigned long prot,
>  884                        unsigned long flags, unsigned long pgoff)
>  885{
>  886        struct mm_struct * mm = current->mm;
>  887        struct vm_area_struct * vma, * prev;
>  888        struct inode *inode;
>  889        unsigned int vm_flags;
>  890        int correct_wcount = 0;
>  891        int error;
>  892        struct rb_node ** rb_link, * rb_parent;
>  893        int accountable = 1;
>  894        unsigned long charged = 0, reqprot = prot;

Local variables indicate that you are using pre-2.6.23 kernel version
and line numbers point to 2.6.18.

It's a good practice to inform us about your environment:
- OS version (`lsb_release -drc` if it's available or just your simple
yet strict description: Fedora 12, etc.),
- kernel version (`uname -a`),
- gcc version (`gcc --version | head -1`),
- stap+elfutils version (`stap -V 2>&1 | head -1`)
and whether kernel, elfutils and stap are your custom builds.

> and here is the output of   'stap -l ' :
> stap -l 'kernel.function("do_mmap_pgoff@mm/mmap.c")'
> kernel.function("do_mmap_pgoff@mm/mmap.c:901")

It's strange. stap should give you a function entry line number, i.e.
885 in this case.

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.

-- 
Przemysław Pawełczyk