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

[PrzemysÅaw PaweÅczyk <przemyslaw at pawelczyk dot it>]

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