How does stap execute probe aliases?

How does stap execute probe aliases?

[Nan Xiao]

Hi all,

I try to execute the following script from this page
(https://sourceware.org/systemtap/SystemTap_Beginners_Guide/targetavailable.html#available):

# cat two_probes.stp
#!/usr/bin/stap
probe vm.pagefault = kernel.function("__handle_mm_fault@mm/memory.c") ?,
                     kernel.function("handle_mm_fault@mm/memory.c") ?
{
        name = "pagefault"
        write_access = (@defined($flags)
                        ? $flags & FAULT_FLAG_WRITE : $write_access)
        address =  $address
}

# ./two_probes.stp
semantic error: no probes found
Pass 2: analysis failed.  [man error::pass2]

Why can't the stap find the probes? Thanks in advance!

Best Regards
Nan Xiao

Re: How does stap execute probe aliases?

[Frank Ch. Eigler]

xiaonan830818 wrote:

> I try to execute the following script from this page
> (https://sourceware.org/systemtap/SystemTap_Beginners_Guide/targetavailable.html#available):
> [...]
> Why can't the stap find the probes? Thanks in advance!

Because that script defines aliases only (kind of like a #define FOO BAR
in a C program), and doesn't instantiate them (FOO in a C program).
So add

   probe vm.pagefault { /* ... */ }

to your script.

- FChE

Re: How does stap execute probe aliases?

[Nan Xiao]

Hi Frank,

I instantiate the probe like this:

# cat page_fault.stp
#!/usr/bin/stap -v
probe vm.pagefault = kernel.function("__handle_mm_fault@mm/memory.c") ?,
                     kernel.function("handle_mm_fault@mm/memory.c") ?
{
        name = "pagefault"
        write_access = (@defined($flags)
                        ? $flags & FAULT_FLAG_WRITE : $write_access)
        address =  $address
}

probe vm.pagefault
{
        printf("%s:%d 0x%x\n", name, write_access, address);
}

But executing it outputs the following error:

# ./page_fault.stp
Pass 1: parsed user script and 102 library script(s) using
78244virt/28420res/2684shr/26440data kb, in 110usr/20sys/128real ms.
semantic error: unable to find local 'write_access', [man
error::dwarf] dieoffset 0xe3b727 in kernel, near pc 0xffffffff8012a5dc
in __handle_mm_fault ../mm/memory.c (alternatives: $address, $mm,
$flags, $vma)): identifier '$write_access' at ./page_fault.stp:7:34
        source:                         ? $flags & FAULT_FLAG_WRITE :
$write_access)
                                                                      ^

semantic error: failed to retrieve location attribute for 'address'
[man error::dwarf] (dieoffset: 0xe3b744): identifier '$address' at
:8:13
        source:         address =  $address
                                   ^

semantic error: unable to find local 'write_access', [man
error::dwarf] dieoffset 0xe3b727 in kernel, near pc 0xffffffff8012a5dc
in __handle_mm_fault ../mm/memory.c (alternatives: $address, $mm,
$flags, $vma)): identifier '$write_access' at :7:34
        source:                         ? $flags & FAULT_FLAG_WRITE :
$write_access)
                                                                      ^

semantic error: failed to retrieve location attribute for 'address'
[man error::dwarf] (dieoffset: 0xe3b744): identifier '$address' at
:8:13
        source:         address =  $address
                                   ^

semantic error: unable to find local 'write_access', [man
error::dwarf] dieoffset 0xe3b727 in kernel, near pc 0xffffffff8012a5dc
in __handle_mm_fault ../mm/memory.c (alternatives: $address, $mm,
$flags, $vma)): identifier '$write_access' at :7:34
        source:                         ? $flags & FAULT_FLAG_WRITE :
$write_access)
                                                                      ^

semantic error: failed to retrieve location attribute for 'address'
[man error::dwarf] (dieoffset: 0xe3b744): identifier '$address' at
:8:13
        source:         address =  $address
                                   ^

semantic error: unable to find local 'write_access', [man
error::dwarf] dieoffset 0xe3b727 in kernel, near pc 0xffffffff8012a5dc
in __handle_mm_fault ../mm/memory.c (alternatives: $address, $mm,
$flags, $vma)): identifier '$write_access' at :7:34
        source:                         ? $flags & FAULT_FLAG_WRITE :
$write_access)
                                                                      ^

semantic error: failed to retrieve location attribute for 'address'
[man error::dwarf] (dieoffset: 0xe3b744): identifier '$address' at
:8:13
        source:         address =  $address
                                   ^

Pass 2: analyzed script: 3 probe(s), 4 function(s), 1 embed(s), 1
global(s) using 113032virt/63380res/3620shr/61228data kb, in
360usr/80sys/533real ms.
Pass 2: analysis failed.  [man error::pass2]

Checking the probes:
# stap -L 'kernel.function("__handle_mm_fault@mm/memory.c")'
kernel.function("__handle_mm_fault@../mm/memory.c:3752")
# stap -L 'kernel.function("handle_mm_fault@mm/memory.c")'
kernel.function("handle_mm_fault@../mm/memory.c:3832") $mm:struct
mm_struct* $vma:struct vm_area_struct* $address:long unsigned int
$flags:unsigned int

It seems the probes all exist and OK.

Could you give some clues about this error? Thanks in advance!
Best Regards
Nan Xiao


On Sat, Nov 21, 2015 at 12:12 AM, Frank Ch. Eigler <fche@redhat.com> wrote:
>
> xiaonan830818 wrote:
>
>> I try to execute the following script from this page
>> (https://sourceware.org/systemtap/SystemTap_Beginners_Guide/targetavailable.html#available):
>> [...]
>> Why can't the stap find the probes? Thanks in advance!
>
> Because that script defines aliases only (kind of like a #define FOO BAR
> in a C program), and doesn't instantiate them (FOO in a C program).
> So add
>
>    probe vm.pagefault { /* ... */ }
>
> to your script.
>
> - FChE

Re: How does stap execute probe aliases?

[Frank Ch. Eigler]

Hi -


> [...]
> But executing it outputs the following error:
> 
> # ./page_fault.stp
> semantic error: unable to find local 'write_access', [man
> error::dwarf] [...]
> semantic error: failed to retrieve location attribute for 'address'
> [man error::dwarf] (dieoffset: 0xe3b744): identifier '$address' at
> :8:13
> [...]

It means those context variables are not available for this
version/build of your kernel.


> Checking the probes:
> # stap -L 'kernel.function("__handle_mm_fault@mm/memory.c")'
> kernel.function("__handle_mm_fault@../mm/memory.c:3752")
> # stap -L 'kernel.function("handle_mm_fault@mm/memory.c")'
> kernel.function("handle_mm_fault@../mm/memory.c:3832") $mm:struct
> mm_struct* $vma:struct vm_area_struct* $address:long unsigned int
> $flags:unsigned int
> 
> It seems the probes all exist and OK.

Yes.


> Could you give some clues about this error? Thanks in advance!

The error messages give the clue [man error::dwarf] means to run
% man error::dwarf
to see a man page about the issue.

The basic difficulty is that writing portable, long-lived script code
is difficult when it closely targets a rapidly moving target.  This is
mainly why the systemtap tapset exists.  The community does the work
of providing a higher level, more fixed interface (aliases, functions,
etc.) that embody the porting logic.

The part of the documentation you were looking at were related to
learning how to write such portable tapsets.  They are not meant for
verbatim copying by end-users.

If you wish to trace page faults, search through the functional examples
first: https://sourceware.org/systemtap/examples/ - for example
https://sourceware.org/systemtap/examples/#memory/pfaults.stp


- FChE

Re: How does stap execute probe aliases?

[Nan Xiao]

Hi Frank,

Yes, the cause is that "__handle_mm_fault" probe doesn't provide $write_access
and $address.

BTW, when you mention "context variable", is it equal to "target variable"?

Thanks!
Best Regards
Nan Xiao


On Sat, Nov 21, 2015 at 8:55 PM, Frank Ch. Eigler <fche@redhat.com> wrote:
> Hi -
>
>
>> [...]
>> But executing it outputs the following error:
>>
>> # ./page_fault.stp
>> semantic error: unable to find local 'write_access', [man
>> error::dwarf] [...]
>> semantic error: failed to retrieve location attribute for 'address'
>> [man error::dwarf] (dieoffset: 0xe3b744): identifier '$address' at
>> :8:13
>> [...]
>
> It means those context variables are not available for this
> version/build of your kernel.
>
>
>> Checking the probes:
>> # stap -L 'kernel.function("__handle_mm_fault@mm/memory.c")'
>> kernel.function("__handle_mm_fault@../mm/memory.c:3752")
>> # stap -L 'kernel.function("handle_mm_fault@mm/memory.c")'
>> kernel.function("handle_mm_fault@../mm/memory.c:3832") $mm:struct
>> mm_struct* $vma:struct vm_area_struct* $address:long unsigned int
>> $flags:unsigned int
>>
>> It seems the probes all exist and OK.
>
> Yes.
>
>
>> Could you give some clues about this error? Thanks in advance!
>
> The error messages give the clue [man error::dwarf] means to run
> % man error::dwarf
> to see a man page about the issue.
>
> The basic difficulty is that writing portable, long-lived script code
> is difficult when it closely targets a rapidly moving target.  This is
> mainly why the systemtap tapset exists.  The community does the work
> of providing a higher level, more fixed interface (aliases, functions,
> etc.) that embody the porting logic.
>
> The part of the documentation you were looking at were related to
> learning how to write such portable tapsets.  They are not meant for
> verbatim copying by end-users.
>
> If you wish to trace page faults, search through the functional examples
> first: https://sourceware.org/systemtap/examples/ - for example
> https://sourceware.org/systemtap/examples/#memory/pfaults.stp
>
>
> - FChE

Re: How does stap execute probe aliases?

[Frank Ch. Eigler]

Hi -

> BTW, when you mention "context variable", is it equal to "target
> variable"?

Yeah; we tend to use the former in current discussions.  (We should
probably retire the latter from documentation.)

- FChE

Re: How does stap execute probe aliases?

[Nan Xiao]

Hi Frank,

Got it ! Thanks very much for your time and help!!
Best Regards
Nan Xiao


On Mon, Nov 23, 2015 at 9:51 AM, Frank Ch. Eigler <fche@redhat.com> wrote:
> Hi -
>
>> BTW, when you mention "context variable", is it equal to "target
>> variable"?
>
> Yeah; we tend to use the former in current discussions.  (We should
> probably retire the latter from documentation.)
>
> - FChE