* question regarding accessing a target variable
[not found] ` <20081107020842.GG20928@redhat.com>
@ 2009-01-02 22:30 ` Kai Wong
2009-01-03 1:00 ` Frank Ch. Eigler
2009-01-03 1:30 ` Kai Wong
` (3 subsequent siblings)
4 siblings, 1 reply; 10+ messages in thread
From: Kai Wong @ 2009-01-02 22:30 UTC (permalink / raw)
To: systemtap; +Cc: Frank Ch. Eigler
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: question regarding accessing a target variable
[not found] ` <20081107020842.GG20928@redhat.com>
2009-01-02 22:30 ` question regarding accessing a target variable Kai Wong
@ 2009-01-03 1:30 ` Kai Wong
2009-01-03 13:50 ` Frank Ch. Eigler
2009-01-06 0:26 ` Kai Wong
` (2 subsequent siblings)
4 siblings, 1 reply; 10+ messages in thread
From: Kai Wong @ 2009-01-03 1:30 UTC (permalink / raw)
To: systemtap; +Cc: Frank Ch. Eigler
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: question regarding accessing a target variable
2009-01-03 1:30 ` Kai Wong
@ 2009-01-03 13:50 ` Frank Ch. Eigler
0 siblings, 0 replies; 10+ messages in thread
From: Frank Ch. Eigler @ 2009-01-03 13:50 UTC (permalink / raw)
To: Kai Wong; +Cc: systemtap
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: question regarding accessing a target variable
[not found] ` <20081107020842.GG20928@redhat.com>
2009-01-02 22:30 ` question regarding accessing a target variable Kai Wong
2009-01-03 1:30 ` Kai Wong
@ 2009-01-06 0:26 ` Kai Wong
2009-01-24 14:27 ` Kai Wong
[not found] ` <1A193CCB5218B14589B1979BC7D510E00802FAFC@TUS1XCHCLUPIN12.enterprise.veritas.com>
4 siblings, 0 replies; 10+ messages in thread
From: Kai Wong @ 2009-01-06 0:26 UTC (permalink / raw)
To: systemtap; +Cc: Frank Ch. Eigler
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: question regarding accessing a target variable
[not found] ` <20081107020842.GG20928@redhat.com>
` (2 preceding siblings ...)
2009-01-06 0:26 ` Kai Wong
@ 2009-01-24 14:27 ` Kai Wong
2009-01-25 2:44 ` Frank Ch. Eigler
[not found] ` <1A193CCB5218B14589B1979BC7D510E00802FAFC@TUS1XCHCLUPIN12.enterprise.veritas.com>
4 siblings, 1 reply; 10+ messages in thread
From: Kai Wong @ 2009-01-24 14:27 UTC (permalink / raw)
To: systemtap; +Cc: Frank Ch. Eigler
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: question regarding accessing a target variable
2009-01-24 14:27 ` Kai Wong
@ 2009-01-25 2:44 ` Frank Ch. Eigler
0 siblings, 0 replies; 10+ messages in thread
From: Frank Ch. Eigler @ 2009-01-25 2:44 UTC (permalink / raw)
To: Kai Wong; +Cc: systemtap
"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
^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <1A193CCB5218B14589B1979BC7D510E00802FAFC@TUS1XCHCLUPIN12.enterprise.veritas.com>]