Listing probe alias resolution failures

Listing probe alias resolution failures

[patm]

With (version 0.5.14 built 2007-04-30) of systemtap and kernel  
2.6.19.7 (i386), there are a lot (~220) of failures in the tapset like  
the following:



semantic error: no match for probe point while resolving probe point  
vm.write_shared_copy



To get a list of all of these, I pulled out some code from the  
systemtap GUI and made a quick standalone java program "listprobes",  
it works like the following:



$ java listprobes |wc --lines

1502



$ java listprobes

register_event

addevent.sunrpc

addevent.sunrpc.entry

addevent.sunrpc.return

...



$ java listprobes --format

probe register_event{}probe addevent.sunrpc{}probe  
addevent.sunrpc.entry{}probe addevent.sunrpc.

return{}probe addevent.sunrpc.clnt{}...



$ java listprobes --format |stap -p2 -u -

semantic error: no match for probe point while resolving probe point  
sunrpc.clnt.create_client

semantic error: no match for probe point while resolving probe point  
_addevent.sunrpc.clnt.create_client.entry

semantic error: no match for probe point while resolving probe point  
addevent.sunrpc.clnt.create_client.entry

semantic error: no match for probe point while resolving probe point  
sunrpc.clnt.create_client.return

semantic error: no match for probe point while resolving probe point  
_addevent.sunrpc.clnt.create_client.return

semantic error: no match for probe point while resolving probe point  
addevent.sunrpc.clnt.create_client.return

..



These failing probes can be kept track of on bugzilla or be addressed  
or be addressed by the tapset authors directly.

Attached below is the source for the listprobes java program.





Patrick McCormick

pmmccorm at us . ibm . com







import java.io.*;

import java.util.*;

import java.lang.*;





public class listprobes {

	private static boolean format;



public static void main (String[] argv) {

	if (argv.length != 0) format = true;

	else format = false;



	File tapdir = new File ("/usr/local/share/systemtap/tapset");

	String s = catProbes(tapdir);

	parseLevel1 (s);





return;

}



private static void parseLevel1(String s) {

	String prev = null;

	String prev2 = null;

	StringBuilder token = new StringBuilder("");

	char currChar;



	for(int i=0; i<s.length(); i++) {

		currChar = s.charAt(i);



		if(!Character.isWhitespace(currChar) && '}' != currChar && '{' != currChar)

			token.append(currChar);

		else if(token.length() > 0) {

			prev2 = prev;

			prev = token.toString();

			token.delete(0, token.length());

		}



		if(1 == token.length()) {



			if (token.toString().contains (",") &&  
!token.toString().contains("kernel.function")) { /* skip over alias of  
aliases */ }

			else if ("probe".equals(prev2) && "=".equals(token.toString())) {

				do {

					currChar = s.charAt(++i);

					token.append(currChar);

				} while('{' != currChar && i < s.length());



				if (format) System.out.print ("probe " + prev + "{}");

				else System.out.println (prev);



			}

			else { /* keep on moving */ }

		}



	}

} // end of method



private static String catProbes(File handle) {

	StringBuilder sb = new StringBuilder();



	if (handle.isDirectory()) {

		File[] contents = handle.listFiles();

		for (File file: contents) {

			sb.append (catProbes(file));

		}

		return sb.toString();

	}

	else if (handle.getAbsolutePath().endsWith (".stp")) {

		FileInputStream fis = null;

		InputStreamReader bis = null;

		BufferedReader reader = null;

		sb.append ("# file " + handle.getAbsolutePath() + "\n");



		try {

			fis = new FileInputStream (handle);

			bis = new InputStreamReader (fis);

			reader = new BufferedReader(bis);



			while (reader.ready()) sb.append (reader.readLine() + "\n");



				reader.close();

				bis.close();

				fis.close();

			}

			catch (IOException ioe) {

				// FIXME: hookup to logger

				// FIXME: close streams and readers here as well?

			}



		return sb.toString();

	}

	else return "\n"; // some non-tapset file, ignore



} // end of method



}

Re: Listing probe alias resolution failures

[David Smith]

patm@pdx.edu wrote:
> With (version 0.5.14 built 2007-04-30) of systemtap and kernel 2.6.19.7 
> (i386), there are a lot (~220) of failures in the tapset like the 
> following:
> 
> semantic error: no match for probe point while resolving probe point 
> vm.write_shared_copy
> 
> To get a list of all of these, I pulled out some code from the systemtap 
> GUI and made a quick standalone java program "listprobes", it works like 
> the following:

I'm not a java programmer, but it appears like you might be expecting 
every function listed in the tapsets to be resolvable on a particular 
kernel.  This isn't the case.  Let's take an easy example - the probe 
alias syscall.open (in tapset/syscalls2.stp):

=============
probe syscall.open =
		kernel.function("sys_open") ?,
		kernel.function("compat_sys_open") ?,
		kernel.function("sys32_open") ?
{
...
}
=============

This probe alias looks for "sys_open" first, then if it doesn't exist 
looks for "compat_sys_open", then looks for "sys32_open".  If "sys_open" 
exists in your kernel, it isn't an error that "compat_sys_open" and 
"sys32_open" do not exist.

In actual use, if you've gotten "no match for probe point" errors let us 
know and we'll try to fix them.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: Listing probe alias resolution failures

[patm]

Quoting David Smith <dsmith@redhat.com>:

> patm@pdx.edu wrote:
>> With (version 0.5.14 built 2007-04-30) of systemtap and kernel   
>> 2.6.19.7 (i386), there are a lot (~220) of failures in the tapset   
>> like the following:
>>
>> semantic error: no match for probe point while resolving probe   
>> point vm.write_shared_copy
>>
>> To get a list of all of these, I pulled out some code from the   
>> systemtap GUI and made a quick standalone java program   
>> "listprobes", it works like the following:
>
> I'm not a java programmer, but it appears like you might be expecting
> every function listed in the tapsets to be resolvable on a particular
> kernel.  This isn't the case.  Let's take an easy example - the probe
> alias syscall.open (in tapset/syscalls2.stp):
>
> =============
> probe syscall.open =
> 		kernel.function("sys_open") ?,
> 		kernel.function("compat_sys_open") ?,
> 		kernel.function("sys32_open") ?
> {
> ...
> }
> =============

The java program lists all of the probe aliases, not their  
corresponding kernel funtion(s). So all of the failures listed are for  
the probe alias, which must happen as you described above, after  
exhausting all listed kernel.functions and modules mapped to in the  
probe definition.

> This probe alias looks for "sys_open" first, then if it doesn't exist
> looks for "compat_sys_open", then looks for "sys32_open".  If
> "sys_open" exists in your kernel, it isn't an error that
> "compat_sys_open" and "sys32_open" do not exist.
>
> In actual use, if you've gotten "no match for probe point" errors let
> us know and we'll try to fix them.
>
> -- 
> David Smith
> dsmith@redhat.com
> Red Hat
> http://www.redhat.com
> 256.217.0141 (direct)
> 256.837.0057 (fax)

Re: Listing probe alias resolution failures

[Mike Mason]

David Smith wrote:
> patm@pdx.edu wrote:
>> With (version 0.5.14 built 2007-04-30) of systemtap and kernel 
>> 2.6.19.7 (i386), there are a lot (~220) of failures in the tapset like 
>> the following:
>>
>> semantic error: no match for probe point while resolving probe point 
>> vm.write_shared_copy
>>
>> To get a list of all of these, I pulled out some code from the 
>> systemtap GUI and made a quick standalone java program "listprobes", 
>> it works like the following:
> 
> I'm not a java programmer, but it appears like you might be expecting 
> every function listed in the tapsets to be resolvable on a particular 
> kernel.  This isn't the case.  Let's take an easy example - the probe 
> alias syscall.open (in tapset/syscalls2.stp):
> 
> =============
> probe syscall.open =
>         kernel.function("sys_open") ?,
>         kernel.function("compat_sys_open") ?,
>         kernel.function("sys32_open") ?
> {
> ...
> }
> =============
> 
> This probe alias looks for "sys_open" first, then if it doesn't exist 
> looks for "compat_sys_open", then looks for "sys32_open".  If "sys_open" 
> exists in your kernel, it isn't an error that "compat_sys_open" and 
> "sys32_open" do not exist.

Unless something has changed, I don't think that's how it works.  The '?' suffix just tells stap not to report an error if the function can't be found.  Stap still looks for all three functions.  For example, if sys_open and compat_sys_open are both found then both have probes placed on them.

Mike

> 
> In actual use, if you've gotten "no match for probe point" errors let us 
> know and we'll try to fix them.
> 

Re: Listing probe alias resolution failures

[patm]

Quoting David Smith <dsmith@redhat.com>:

> patm@pdx.edu wrote:
>> With (version 0.5.14 built 2007-04-30) of systemtap and kernel   
>> 2.6.19.7 (i386), there are a lot (~220) of failures in the tapset   
>> like the following:
>>
>> semantic error: no match for probe point while resolving probe   
>> point vm.write_shared_copy
>>
>> To get a list of all of these, I pulled out some code from the   
>> systemtap GUI and made a quick standalone java program   
>> "listprobes", it works like the following:
>
> I'm not a java programmer, but it appears like you might be expecting
> every function listed in the tapsets to be resolvable on a particular
> kernel.  This isn't the case.  Let's take an easy example - the probe
> alias syscall.open (in tapset/syscalls2.stp):

I was thinking the java program is pretty obscure, so here is a much  
simpler way to determine some of the probe aliases that are failing,  
in this case lets look at syscalls.stp:

$ grep syscall.*= /usr/share/systemtap/tapset/syscalls.stp | \
awk '{ print $1 " " $2 "{}" }' | \
stap -p2 -u -

And either a list of failed probe alias resolutions will be printed to  
stderr, or a list of probe aliases, variables, and functions will be  
printed out to stdout.

Re: Listing probe alias resolution failures

[David Smith]

Mike Mason wrote:
> David Smith wrote:
>
>> This probe alias looks for "sys_open" first, then if it doesn't exist 
>> looks for "compat_sys_open", then looks for "sys32_open".  If 
>> "sys_open" exists in your kernel, it isn't an error that 
>> "compat_sys_open" and "sys32_open" do not exist.
> 
> Unless something has changed, I don't think that's how it works.  The 
> '?' suffix just tells stap not to report an error if the function can't 
> be found.  Stap still looks for all three functions.  For example, if 
> sys_open and compat_sys_open are both found then both have probes placed 
> on them.

Oops, you're right.  That's what I get for writing that in a hurry.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: Listing probe alias resolution failures

[David Smith]

patm@pdx.edu wrote:
> I was thinking the java program is pretty obscure, so here is a much 
> simpler way to determine some of the probe aliases that are failing, in 
> this case lets look at syscalls.stp:
> 
> $ grep syscall.*= /usr/share/systemtap/tapset/syscalls.stp | \
> awk '{ print $1 " " $2 "{}" }' | \
> stap -p2 -u -
> 
> And either a list of failed probe alias resolutions will be printed to 
> stderr, or a list of probe aliases, variables, and functions will be 
> printed out to stdout.
> 

On my FC6.93 system, here are the errors the above outputs:

semantic error: no match for probe point while resolving probe point 
syscall.compat_getitimer
semantic error: no match for probe point while resolving probe point 
syscall.compat_getitimer.return
semantic error: no match for probe point while resolving probe point 
syscall.get_mempolicy
semantic error: no match for probe point while resolving probe point 
syscall.get_mempolicy.return
semantic error: no match for probe point while resolving probe point 
syscall.mbind
semantic error: no match for probe point while resolving probe point 
syscall.mbind.return
semantic error: no match for probe point while resolving probe point 
syscall.mmap
semantic error: no match for probe point while resolving probe point 
syscall.mmap.return

Let's look at the first one for a sec.  The system call 
"compat_getitimer" doesn't exist on my x86 FC6.93 system.  It does exist 
on a x86_64 RHEL4 system I have access to.

So, how does this hurt me?  The below 2 stap commands still work:

# stap -p2 -u -e 'probe syscall.* {}'
# stap -p2 -u -e 'probe syscall.*getitimer {}'

The only thing that doesn't work is:

# stap -p2 -u -e 'probe syscall.compat_getitimer {}'

So, the only error I get is when I explicitly list the system call that 
doesn't exist on my current arch and kernel.  I could see where if you 
were writing a script targeting either multiple architectures or 
multiple kernel versions that might bother you.  However, the solution 
is easy - make that probe optional:

# stap -p2 -u -e 'probe syscall.compat_getitimer ? { }'

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: Listing probe alias resolution failures

[patm]

Quoting David Smith <dsmith@redhat.com>:

> patm@pdx.edu wrote:
>> I was thinking the java program is pretty obscure, so here is a   
>> much simpler way to determine some of the probe aliases that are   
>> failing, in this case lets look at syscalls.stp:
>>
>> $ grep syscall.*= /usr/share/systemtap/tapset/syscalls.stp | \
>> awk '{ print $1 " " $2 "{}" }' | \
>> stap -p2 -u -
>>
>> And either a list of failed probe alias resolutions will be printed  
>>  to stderr, or a list of probe aliases, variables, and functions   
>> will be printed out to stdout.
>>
>
> On my FC6.93 system, here are the errors the above outputs:
>
> semantic error: no match for probe point while resolving probe point
> syscall.compat_getitimer
> semantic error: no match for probe point while resolving probe point
> syscall.compat_getitimer.return
> semantic error: no match for probe point while resolving probe point
> syscall.get_mempolicy
> semantic error: no match for probe point while resolving probe point
> syscall.get_mempolicy.return
> semantic error: no match for probe point while resolving probe point
> syscall.mbind
> semantic error: no match for probe point while resolving probe point
> syscall.mbind.return
> semantic error: no match for probe point while resolving probe point
> syscall.mmap
> semantic error: no match for probe point while resolving probe point
> syscall.mmap.return
>
> Let's look at the first one for a sec.  The system call
> "compat_getitimer" doesn't exist on my x86 FC6.93 system.  It does
> exist on a x86_64 RHEL4 system I have access to.
>
> So, how does this hurt me?  The below 2 stap commands still work:
>
> # stap -p2 -u -e 'probe syscall.* {}'
> # stap -p2 -u -e 'probe syscall.*getitimer {}'
>
> The only thing that doesn't work is:
>
> # stap -p2 -u -e 'probe syscall.compat_getitimer {}'
>
> So, the only error I get is when I explicitly list the system call that
> doesn't exist on my current arch and kernel.  I could see where if you
> were writing a script targeting either multiple architectures or
> multiple kernel versions that might bother you.  However, the solution
> is easy - make that probe optional:
>
> # stap -p2 -u -e 'probe syscall.compat_getitimer ? { }'

Very nice, I had no idea that you could do this to a probe alias. But,  
and I don't know if this is intended or not, it still fails on certain  
errors:

$ stap -p2 -u -e 'probe vm.mmap ? { }'
semantic error: failed to retrieve location attribute for local 'addr'  
(dieoffset: 0xb84881): identifier '$addr' at  
/usr/local/share/systemtap/tapset/memory.stp:118:15
semantic error: failed to retrieve location attribute for local 'addr'  
(dieoffset: 0x78276d): identifier '$addr' at  
/usr/local/share/systemtap/tapset/memory.stp:118:15
semantic error: failed to retrieve location attribute for local 'addr'  
(dieoffset: 0x780d54): identifier '$addr' at  
/usr/local/share/systemtap/tapset/memory.stp:118:15
semantic error: failed to retrieve location attribute for local 'addr'  
(dieoffset: 0x780bc4): identifier '$addr' at  
/usr/local/share/systemtap/tapset/memory.stp:118:15
semantic error: failed to retrieve location attribute for local 'addr'  
(dieoffset: 0x6b504d): identifier '$addr' at  
/usr/local/share/systemtap/tapset/memory.stp:118:15
semantic error: failed to retrieve location attribute for local 'len'  
(dieoffset: 0xb8487c): identifier '$len' at  
/usr/local/share/systemtap/tapset/memory.stp:119:14
semantic error: failed to retrieve location attribute for local 'len'  
(dieoffset: 0x782768): identifier '$len' at  
/usr/local/share/systemtap/tapset/memory.stp:119:14
semantic error: not accessible at this address: identifier '$len' at  
/usr/local/share/systemtap/tapset/memory.stp:119:14
semantic error: failed to retrieve location attribute for local 'len'  
(dieoffset: 0x780bbf): identifier '$len' at  
/usr/local/share/systemtap/tapset/memory.stp:119:14
semantic error: probe_1527 with unresolved type for identifier  
'address' at /usr/local/share/systemtap/tapset/memory.stp:118:5
semantic error: probe_1528 with unresolved type for identifier  
'address' at /usr/local/share/systemtap/tapset/memory.stp:118:5
semantic error: probe_1528 with unresolved type for identifier  
'length' at /usr/local/share/systemtap/tapset/memory.stp:119:5
semantic error: probe_1529 with unresolved type for identifier  
'address' at /usr/local/share/systemtap/tapset/memory.stp:118:5
semantic error: probe_1529 with unresolved type for identifier  
'length' at /usr/local/share/systemtap/tapset/memory.stp:119:5
semantic error: probe_1530 with unresolved type for identifier  
'address' at /usr/local/share/systemtap/tapset/memory.stp:118:5
semantic error: probe_1530 with unresolved type for identifier  
'length' at /usr/local/share/systemtap/tapset/memory.stp:119:5
semantic error: probe_1531 with unresolved type for identifier  
'address' at /usr/local/share/systemtap/tapset/memory.stp:118:5
semantic error: probe_1531 with unresolved type for identifier  
'length' at /usr/local/share/systemtap/tapset/memory.stp:119:5
Pass 2: analysis failed.  Try again with more '-v' (verbose) options.

Re: Listing probe alias resolution failures

[David Smith]

patm@pdx.edu wrote:
> Quoting David Smith <dsmith@redhat.com>:
>> The only thing that doesn't work is:
>>
>> # stap -p2 -u -e 'probe syscall.compat_getitimer {}'
>>
>> So, the only error I get is when I explicitly list the system call that
>> doesn't exist on my current arch and kernel.  I could see where if you
>> were writing a script targeting either multiple architectures or
>> multiple kernel versions that might bother you.  However, the solution
>> is easy - make that probe optional:
>>
>> # stap -p2 -u -e 'probe syscall.compat_getitimer ? { }'
> 
> Very nice, I had no idea that you could do this to a probe alias. But, 
> and I don't know if this is intended or not, it still fails on certain 
> errors:
> 
> $ stap -p2 -u -e 'probe vm.mmap ? { }'
> semantic error: failed to retrieve location attribute for local 'addr' 
> (dieoffset: 0xb84881): identifier '$addr' at 

Hmm.

Here I've got good news and bad news.  The good news is that if you take 
away the '-u', then your example works (since the optimizer removes 
references to the variables that aren't read).

The bad news is that if you reference the local variable version of the 
function's parameters in your optional probe, it errors out, like this:

# stap -p2 -e 'probe vm.mmap ? { printf("%p %d\n", address, length) }'
semantic error: failed to retrieve location attribute for local 'addr' 
(dieoffset: 0xbf6524): identifier '$addr' at 
/usr/local/share/systemtap/tapset/memory.stp:118:15
...

Here it seems like we should be able to discard the probe before trying 
to look up its parameters.

Could you file a bugzilla on this so we don't forget to look at this?

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: Listing probe alias resolution failures

[Frank Ch. Eigler]

David Smith <dsmith@redhat.com> writes:

> > $ stap -p2 -u -e 'probe vm.mmap ? { }'
> > semantic error: failed to retrieve location attribute for local
> > 'addr' (dieoffset: 0xb84881): identifier '$addr' at
> 
> [...]
> # stap -p2 -e 'probe vm.mmap ? { printf("%p %d\n", address, length) }'
> semantic error: failed to retrieve location attribute for local 'addr'
> (dieoffset: 0xbf6524): identifier '$addr' at
> /usr/local/share/systemtap/tapset/memory.stp:118:15

Indeed, this is probably an instance of PR 1155, and one of the
reasons for the optimization pass in the first place.  It's partly

> Here it seems like we should be able to discard the probe before
> trying to look up its parameters.  Could you file a bugzilla on this
> so we don't forget to look at this?

Specifically, are you suggesting that

   probe kernel.function("something_that_exists") ? { 
      f($non_existent_variable) 
   }

should be accepted?

- FChE

Re: Listing probe alias resolution failures

[patm]

Quoting David Smith <dsmith@redhat.com>:

> patm@pdx.edu wrote:
>> Quoting David Smith <dsmith@redhat.com>:
>>> The only thing that doesn't work is:
>>>
>>> # stap -p2 -u -e 'probe syscall.compat_getitimer {}'
>>>
>>> So, the only error I get is when I explicitly list the system call that
>>> doesn't exist on my current arch and kernel.  I could see where if you
>>> were writing a script targeting either multiple architectures or
>>> multiple kernel versions that might bother you.  However, the solution
>>> is easy - make that probe optional:
>>>
>>> # stap -p2 -u -e 'probe syscall.compat_getitimer ? { }'
>>
>> Very nice, I had no idea that you could do this to a probe alias.   
>> But, and I don't know if this is intended or not, it still fails on  
>>  certain errors:
>>
>> $ stap -p2 -u -e 'probe vm.mmap ? { }'
>> semantic error: failed to retrieve location attribute for local   
>> 'addr' (dieoffset: 0xb84881): identifier '$addr' at
>
> Hmm.
>
> Here I've got good news and bad news.  The good news is that if you
> take away the '-u', then your example works (since the optimizer
> removes references to the variables that aren't read).
>
> The bad news is that if you reference the local variable version of the
> function's parameters in your optional probe, it errors out, like this:
>
> # stap -p2 -e 'probe vm.mmap ? { printf("%p %d\n", address, length) }'
> semantic error: failed to retrieve location attribute for local 'addr'
> (dieoffset: 0xbf6524): identifier '$addr' at
> /usr/local/share/systemtap/tapset/memory.stp:118:15
> ...
>
> Here it seems like we should be able to discard the probe before trying
> to look up its parameters.
>
> Could you file a bugzilla on this so we don't forget to look at this?

I'll file a bug later today. Also, I have found some probes that don't  
seem to behave correctly when used with that conditional (?) :

$ stap -p2 -u -e 'probe syscall.compat_sys_times {}'
...mismatch...cannot resolve probe point syscall.compat_sys_times

$ stap -p2 -u -e 'probe syscall.compat_sys_times? {}'
...mismatch...cannot resolve probe point syscall.compat_sys_times

Mostly syscall probes, especially syscall.compat_* , and  
signal.handle_stop is another example.

Re: Listing probe alias resolution failures

[David Smith]

Frank Ch. Eigler wrote:
> David Smith <dsmith@redhat.com> writes:
>> Here it seems like we should be able to discard the probe before
>> trying to look up its parameters.  Could you file a bugzilla on this
>> so we don't forget to look at this?
> 
> Specifically, are you suggesting that
> 
>    probe kernel.function("something_that_exists") ? { 
>       f($non_existent_variable) 
>    }
> 
> should be accepted?

Nope, I'm suggesting that:

    probe kernel.function("something_that_does_not_exist") ? {
       local1 = $arg1
       local2 = $arg2
       printf("%d %d\n", local1, local2)
    }

be accepted.

In other words, if we know a probe point doesn't exist, it shouldn't 
matter what arguments it references.

If we make this change, it will make it easier to write scripts that 
target multiple kernel versions and/or architectures.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: Listing probe alias resolution failures

[Frank Ch. Eigler]

Hi -

On Wed, May 16, 2007 at 03:17:55PM -0500, David Smith wrote:
> [...]
> Nope, I'm suggesting that:
>    probe kernel.function("something_that_does_not_exist") ? {
>       local1 = $arg1
>       local2 = $arg2
>       printf("%d %d\n", local1, local2)
>    }
> be accepted.

But it is already.


> In other words, if we know a probe point doesn't exist, it shouldn't
> matter what arguments it references. [...]

It doesn't.


- FChE

Re: Listing probe alias resolution failures

[David Smith]

Frank Ch. Eigler wrote:
> Hi -
> 
> On Wed, May 16, 2007 at 03:17:55PM -0500, David Smith wrote:
>> [...]
>> Nope, I'm suggesting that:
>>    probe kernel.function("something_that_does_not_exist") ? {
>>       local1 = $arg1
>>       local2 = $arg2
>>       printf("%d %d\n", local1, local2)
>>    }
>> be accepted.
> 
> But it is already.
> 
> 
>> In other words, if we know a probe point doesn't exist, it shouldn't
>> matter what arguments it references. [...]
> 
> It doesn't.

Hmm, I see what you mean.  The following doesn't give an error for 
accessing $arg (although it does rightly complain that "no probes found").

# stap -p2 -e 'probe kernel.function("fche") ? { $arg1++ }'


Ah, I see something I missed before with the following:

# stap -p2 -e 'probe vm.mmap ? { printf("%p %d\n", address, length) }'

Here's the definition from tapset/memory.stp:

probe vm.mmap = kernel.function("do_mmap"), kernel.function("do_mmap2")? {
     address = $addr
     length = $len
}

I missed the fact that the first one isn't optional.  But, shouldn't 
making 'vm.mmap' optional basically make 'kernel.function("do_mmap")' 
optional?

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: Listing probe alias resolution failures

[Frank Ch. Eigler]

Hi -

> [...]
> Ah, I see something I missed before with the following:
> # stap -p2 -e 'probe vm.mmap ? { printf("%p %d\n", address, length) }'
> [...]
> probe vm.mmap = kernel.function("do_mmap"), kernel.function("do_mmap2")? {
>     address = $addr
>     length = $len
> }
> [...]
> I missed the fact that the first one isn't optional.  But, shouldn't 
> making 'vm.mmap' optional basically make 'kernel.function("do_mmap")' 
> optional?

But "do_mmap" is found, and so the optional flag is satisfied.  The
probe handler is processed without further error suppression.  It's
not obvious that this is wrong. 

PS. This bug #1155 is really annoying.

- FChE

Re: Listing probe alias resolution failures

[Mike Mason]

David Smith wrote:
> Frank Ch. Eigler wrote:
>> Hi -
>>
>> On Wed, May 16, 2007 at 03:17:55PM -0500, David Smith wrote:
>>> [...]
>>> Nope, I'm suggesting that:
>>>    probe kernel.function("something_that_does_not_exist") ? {
>>>       local1 = $arg1
>>>       local2 = $arg2
>>>       printf("%d %d\n", local1, local2)
>>>    }
>>> be accepted.
>>
>> But it is already.
>>
>>
>>> In other words, if we know a probe point doesn't exist, it shouldn't
>>> matter what arguments it references. [...]
>>
>> It doesn't.
> 
> Hmm, I see what you mean.  The following doesn't give an error for 
> accessing $arg (although it does rightly complain that "no probes found").
> 
> # stap -p2 -e 'probe kernel.function("fche") ? { $arg1++ }'
> 
> 
> Ah, I see something I missed before with the following:
> 
> # stap -p2 -e 'probe vm.mmap ? { printf("%p %d\n", address, length) }'
> 
> Here's the definition from tapset/memory.stp:
> 
> probe vm.mmap = kernel.function("do_mmap"), kernel.function("do_mmap2")? {
>     address = $addr
>     length = $len
> }
> 
> I missed the fact that the first one isn't optional.  But, shouldn't 
> making 'vm.mmap' optional basically make 'kernel.function("do_mmap")' 
> optional?
> 

That's how it's documented to work.  From stapprobes(5): "Optionalness  passes  down  through  all levels of alias/wildcard expansion."

As for certain variables being inaccessible, isn't this just the on-going problem that symbols are sometimes unpredictably optimized away.  As I've said before, I think the test suite should check for this (i.e., -u tests), but it currently doesn't.

Mike

Re: Listing probe alias resolution failures

[David Smith]

Frank Ch. Eigler wrote:
> Hi -
> 
>> [...]
>> Ah, I see something I missed before with the following:
>> # stap -p2 -e 'probe vm.mmap ? { printf("%p %d\n", address, length) }'
>> [...]
>> probe vm.mmap = kernel.function("do_mmap"), kernel.function("do_mmap2")? {
>>     address = $addr
>>     length = $len
>> }
>> [...]
>> I missed the fact that the first one isn't optional.  But, shouldn't 
>> making 'vm.mmap' optional basically make 'kernel.function("do_mmap")' 
>> optional?
> 
> But "do_mmap" is found, and so the optional flag is satisfied.  The
> probe handler is processed without further error suppression.  It's
> not obvious that this is wrong. 

I guess I was thinking that the "optionalness" of vm.mmap would have 
meant that when do_mmap wasn't found, vm.mmap would be tossed (so that 
there would be no attempt to look up $addr and $len)

Perhaps the real bug is that the kernel.function("do_mmap") should be 
made optional in the vm.mmap probe alias.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: Listing probe alias resolution failures

[Stone, Joshua I]

David Smith wrote:
> I guess I was thinking that the "optionalness" of vm.mmap would have 
> meant that when do_mmap wasn't found, vm.mmap would be tossed (so that 
> there would be no attempt to look up $addr and $len)

This is exactly right.  But in this case, do_mmap *is* found, so the 
"optionalness" resolves to a real probe point.  If you add a "-vv" to 
your command line, you'll see which probe points get resolved.  Once you 
have a probe point, then it has to resolve the body, so the parameters 
become an issue.

I think Frank had an idea for conditional target variables a while back, 
but I can't find the email.  Perhaps that's an idea that needs to be 
revived?

> Perhaps the real bug is that the kernel.function("do_mmap") should be 
> made optional in the vm.mmap probe alias.

I think in this case do_mmap is found, so the only bug is #1155 
resolving inline parameters...


Josh

Re: Listing probe alias resolution failures

[Frank Ch. Eigler]

"Stone, Joshua I" <joshua.i.stone@intel.com> writes:

> [...]  I think in this case do_mmap is found, so the only bug is
> #1155 resolving inline parameters...

Alex Oliva has one starter patch for this gcc problem, but would
appreciate help testing it.  It would require rebuilding the compiler,
and rebuilding the kernel with that compiler.

http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00703.html

- FChE