This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: SYSTEMTAP TEST RESULTS : Kernel version 2.6.35-rc3 on POWER ppc64 architecture.


On Thu, 2010-06-24 at 14:03 -0500, David Smith wrote:
> On 06/24/2010 02:10 AM, Divya Vikas wrote:
> >> FAIL: buildok/syscall.stp
> > 
> > This one is failing in syscall.pipe.
> > 
> > Could you run the following command and show me the output: stap -L
> > syscall.pipe
> > 
> > semantic error: invalid access '[0]' vs. long int: operator '['
> > at /usr/local/share/systemtap/tapset/syscalls2.stp:312:29
> >         source: 			pipe0 = user_int(&$fildes[0]);
> >                 			                         ^
> > semantic error: invalid access '[1]' vs. long int: operator '[' at :313:29
> >         source: 			pipe1 = user_int(&$fildes[1]);
> >                 			                         ^
> > syscall.pipe flags:long flag_str:string name:string fildes_uaddr:long
> > pipe0:long pipe1:long argstr:string $fildes:long int $flags:long int
> 
> That one is weird.  Systemtap thinks that '$fildes' is a 'long int', not
> a 'long int *'.  From looking at the current kernel source it appears
> that $fildes is still a pointer.  I got access to a f12 ppc64 machine
> (running 2.6.32.12-115.fc12.ppc64) and it shows the same problems:
> 
> # stap -L 'kernel.function("sys_pipe").call'
> kernel.function("SyS_pipe@fs/pipe.c:1117").call $fildes:long int
> # stap -L 'kernel.function("sys_pipe2").call'
> kernel.function("SyS_pipe2@fs/pipe.c:1101").call $fildes:long int
> $flags:long int
> 
> Mark, do you have any ideas here?

Strange. That must the debuginfo is telling us that is the type. Which
would indicate a gcc bug I presume.

Could you see what loc2c-test says about it?

When running with stap -vvv -L 'kernel.function("sys_pipe").call' it
should output something like: finding location for local 'fildes' near
address 0xc04cea4c, module bias 0x0

Then try:
./loc2c-test -e /usr/lib/debug/lib/modules/*/vmlinux 0xc04cea4c

Which should tell what we think can be accessed and what the types are
around that address.

Then try:
./loc2c-test -e /usr/lib/debug/lib/modules/*/vmlinux 0xc04cea4c fildes

Which should tell how we think fildes needs to be accessed.

Cheers,

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]