help needed to probe own modules

help needed to probe own modules

[Kai_Wong]

I'm a new systemtap user and am trying to use it to probe my own kernel
modules. I'm successful in running sample scripts such as top.stp in
/usr/share/doc/systemtap-0.5.12 on a RHEL 5 system.

I can also do things like:
stap -e 'probe module("ext3").function("*") {printf("%d %s(%d)\n",
gettimeofday_s(), execname(), pid())}'

However, for a module, vxlogmod, that I made and added using insmod and
showed up under lsmod:
[root@srlglm1 vxlog]#lsmod
Module                  Size  Used by
 ... <snipped> ...
vxlogmod              317560  1 vxglm

stap gave the following error:
# stap -e 'probe module("vxlogmod").function("*") {}'
semantic error: no match for probe point while resolving probe point
module("vxlogmod").function("*")
Pass 2: analysis failed.  Try again with more '-v' (verbose) options.

So, my questions are:
1. Does systemtap on RHEL5 support probing kernel modules that are built and
installed separately from the distro kernel?
2. If so, what do I need to do to make it recognize my modules?

Any help will be much appreciated.
Best,
Kai
-- 
View this message in context: http://www.nabble.com/help-needed-to-probe-own-modules-tp20217654p20217654.html
Sent from the Sourceware - systemtap mailing list archive at Nabble.com.

Re: help needed to probe own modules

[Frank Ch. Eigler]

Kai_Wong <kai_wong@symantec.com> writes:

> [...]
> However, for a module, vxlogmod, that I made and added using insmod and
> showed up under lsmod:
> [root@srlglm1 vxlog]#lsmod
> Module                  Size  Used by
>  ... <snipped> ...
> vxlogmod              317560  1 vxglm
>
> stap gave the following error:
> # stap -e 'probe module("vxlogmod").function("*") {}'
> semantic error: no match for probe point while resolving probe point
> module("vxlogmod").function("*")
> [...]

You need to find out where vxlogmod.ko's debugging data is.  If your
build system does not strip it, it should still be in there.  Then you
just need to copy it to a place where systemtap will look for it by
default (such as /lib/modules/`uname -r`/ANYTHING), or make systemtap
look for it where you do have it (by adding the directory to the
SYSTEMTAP_DEBUGINFO_PATH environment variable appropriately; see
stap.1 for the default).


- FChE

question regarding accessing a target variable

[Kai Wong]

Hi,

I try to access a target variable (e.g., block, which is a c local
variable within a probed function), but no matter what line number I
place the probe within the function (e.g., probe
module("vxglm").statement("vxg_recv_block_grant@/home2/kwong/glm-bld/50m
p3_clustrace/kernel/glm/smp/glmbpxy.c:67")), I get the following
message:

semantic error: not accessible at this address: identifier '$block' at
/usr/share/systemtap/tapset/glm/msgsup.stp:20:123

that target variable was actually assigned a valid value and referenced
in many different lines within the probed function. I have no trouble
with other target variables that are c local variables.

What can I do to make a c local variable more accessible to systemtap as
a target variable?

Kai 

Re: question regarding accessing a target variable

[Frank Ch. Eigler]

Hi -

On Fri, Jan 02, 2009 at 03:29:04PM -0700, Kai Wong wrote:
> [...]
> (e.g., probe
> module("vxglm").statement("vxg_recv_block_grant@/home2/kwong/glm-bld/50m
> p3_clustrace/kernel/glm/smp/glmbpxy.c:67")), I get the following
> message:
> 
> semantic error: not accessible at this address: identifier '$block' at
> /usr/share/systemtap/tapset/glm/msgsup.stp:20:123
> [...]
> What can I do to make a c local variable more accessible to systemtap as
> a target variable?

I jotted some melancholy notes on this in the wiki.
http://sources.redhat.com/systemtap/wiki/TipContextVariables

- FChE

RE: question regarding accessing a target variable

[Kai Wong]

FChE wrote:
> I jotted some melancholy notes on this in the wiki.
> http://sources.redhat.com/systemtap/wiki/TipContextVariables

If none of the other options applies or works, but I can modify the
source of the probed software, does
inserting inline-assembly directives as shown in that example slow down
the performance of the probed software when not probed (assuming the
"volatile" directives stays)?

-Kai

-----Original Message-----
From: Kai Wong 
Sent: Friday, January 02, 2009 2:29 PM
To: 'systemtap@sources.redhat.com'
Cc: 'Frank Ch. Eigler'
Subject: question regarding accessing a target variable

Hi,

I try to access a target variable (e.g., block, which is a c local
variable within a probed function), but no matter what line number I
place the probe within the function (e.g., probe
module("vxglm").statement("vxg_recv_block_grant@/home2/kwong/glm-bld/50m
p3_clustrace/kernel/glm/smp/glmbpxy.c:67")), I get the following
message:

semantic error: not accessible at this address: identifier '$block' at
/usr/share/systemtap/tapset/glm/msgsup.stp:20:123

that target variable was actually assigned a valid value and referenced
in many different lines within the probed function. I have no trouble
with other target variables that are c local variables.

What can I do to make a c local variable more accessible to systemtap as
a target variable?

Kai 

Re: question regarding accessing a target variable

[Frank Ch. Eigler]

Hi -

On Fri, Jan 02, 2009 at 06:28:59PM -0700, Kai Wong wrote:

> [...]  If none of the other options applies or works, but I can
> modify the source of the probed software, does inserting
> inline-assembly directives as shown in that example slow down the
> performance of the probed software when not probed (assuming the
> "volatile" directives stays)?

It should not, in any material way.  You can confirm with measurements
of course, or by looking over the assembly/object code before & after.

- FChE

RE: question regarding accessing a target variable

[Kai Wong]

FChE wrote:
> It should not, in any material way.  You can confirm with measurements
> of course, or by looking over the assembly/object code before & after.

It works, without any measurable performance degradation. Thank you very
much!!
-Kai

-----Original Message-----
From: Kai Wong 
Sent: Friday, January 02, 2009 5:29 PM
To: 'systemtap@sources.redhat.com'
Cc: 'Frank Ch. Eigler'
Subject: RE: question regarding accessing a target variable

FChE wrote:
> I jotted some melancholy notes on this in the wiki.
> http://sources.redhat.com/systemtap/wiki/TipContextVariables

If none of the other options applies or works, but I can modify the
source of the probed software, does
inserting inline-assembly directives as shown in that example slow down
the performance of the probed software when not probed (assuming the
"volatile" directives stays)?

-Kai

-----Original Message-----
From: Kai Wong 
Sent: Friday, January 02, 2009 2:29 PM
To: 'systemtap@sources.redhat.com'
Cc: 'Frank Ch. Eigler'
Subject: question regarding accessing a target variable

Hi,

I try to access a target variable (e.g., block, which is a c local
variable within a probed function), but no matter what line number I
place the probe within the function (e.g., probe
module("vxglm").statement("vxg_recv_block_grant@/home2/kwong/glm-bld/50m
p3_clustrace/kernel/glm/smp/glmbpxy.c:67")), I get the following
message:

semantic error: not accessible at this address: identifier '$block' at
/usr/share/systemtap/tapset/glm/msgsup.stp:20:123

that target variable was actually assigned a valid value and referenced
in many different lines within the probed function. I have no trouble
with other target variables that are c local variables.

What can I do to make a c local variable more accessible to systemtap as
a target variable?

Kai 

RE: question regarding accessing a target variable

[Kai Wong]

Hi,

Although the "volatile" directive as in
<http://sources.redhat.com/systemtap/wiki/TipContextVariables> works in
most cases, it doesn't help if the target variable is used to merely
cast a function parameter as something else. For example, if I have a
probe to the following function:

void dummy_function(void *a) {
	typedef struct {
		int	x;
		int	y;
	} b_t; 
	b_t *b = (b_t*)a;
	 ...
}

I can't access the target variables x and y in a systemtap script using
$b->x and $b->y (I get " semantic error: not accessible at this
address").

Is there any support in the systemtap script language that lets me
access x and y without having to write a separate embedded-c function
for each as follows?

%{
	typedef struct {
		int	x;
		int	y;
	} b_t; 
%}

function get_x:long (a:long) %{
	b_t *b = (b_t *)(long)THIS->a;
	THIS->__retvalue = deref(sizeof(b->x), &(b->x));
	if (0) {
deref_fault:
		CONTEXT->last_error = "pointer dereference fault";
	}
%}

function get_y:long (a:long) %{
	b_t *b = (b_t *)(long)THIS->a;
	THIS->__retvalue = deref(sizeof(b->y), &(b->y));
	if (0) {
deref_fault:
		CONTEXT->last_error = "pointer dereference fault";
	}
%}

Or, if you see a simpler method to this, that'll also be helpful.

Kai


-----Original Message-----
From: Kai Wong 
Sent: Monday, January 05, 2009 4:25 PM
To: 'systemtap@sources.redhat.com'
Cc: 'Frank Ch. Eigler'
Subject: RE: question regarding accessing a target variable
Importance: High

FChE wrote:
> It should not, in any material way.  You can confirm with measurements
> of course, or by looking over the assembly/object code before & after.

It works, without any measurable performance degradation. Thank you very
much!!
-Kai

-----Original Message-----
From: Kai Wong 
Sent: Friday, January 02, 2009 5:29 PM
To: 'systemtap@sources.redhat.com'
Cc: 'Frank Ch. Eigler'
Subject: RE: question regarding accessing a target variable

FChE wrote:
> I jotted some melancholy notes on this in the wiki.
> http://sources.redhat.com/systemtap/wiki/TipContextVariables

If none of the other options applies or works, but I can modify the
source of the probed software, does
inserting inline-assembly directives as shown in that example slow down
the performance of the probed software when not probed (assuming the
"volatile" directives stays)?

-Kai

-----Original Message-----
From: Kai Wong 
Sent: Friday, January 02, 2009 2:29 PM
To: 'systemtap@sources.redhat.com'
Cc: 'Frank Ch. Eigler'
Subject: question regarding accessing a target variable

Hi,

I try to access a target variable (e.g., block, which is a c local
variable within a probed function), but no matter what line number I
place the probe within the function (e.g., probe
module("vxglm").statement("vxg_recv_block_grant@/home2/kwong/glm-bld/50m
p3_clustrace/kernel/glm/smp/glmbpxy.c:67")), I get the following
message:

semantic error: not accessible at this address: identifier '$block' at
/usr/share/systemtap/tapset/glm/msgsup.stp:20:123

that target variable was actually assigned a valid value and referenced
in many different lines within the probed function. I have no trouble
with other target variables that are c local variables.

What can I do to make a c local variable more accessible to systemtap as
a target variable?

Kai 

Re: question regarding accessing a target variable

[Frank Ch. Eigler]

"Kai Wong" <kai_wong@symantec.com> writes:

> [...]
> void dummy_function(void *a) {
> 	typedef struct {
> 		int	x;
> 		int	y;
> 	} b_t;
> 	b_t *b = (b_t*)a;
> 	 ...
> }
>
> I can't access the target variables x and y in a systemtap script using
> $b->x and $b->y (I get " semantic error: not accessible at this
> address").
>
> Is there any support in the systemtap script language that lets me
> access x and y without having to write a separate embedded-c function
> for each as follows?
> [...]

I think sources.redhat.com/PR6704 (now 5634) should at some point
cover this, by allowing you write the cast from void* to "struct b_t".

Our pointer/typing operations are currently rather limited.  I've been
hoping that we wouldn't need the whole C suite of */&/(cast), but
maybe we'll have to bite that bullet and build it.

- FChE

Re: question regarding accessing a target variable

[Frank Ch. Eigler]

Hi -

kai_wong wrote:

> I don't see a resolution for PR 5634. Does it mean that there is still
> no casting and I still have to write embedded c-code to get around? [...]

Yes, that is unfortunately correct.

- FChE