This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
RE: About function parameter access
- From: "Mao, Bibo" <bibo dot mao at intel dot com>
- To: "Roland McGrath" <roland at redhat dot com>
- Cc: <systemtap at sources dot redhat dot com>
- Date: Fri, 18 Nov 2005 16:02:30 +0800
- Subject: RE: About function parameter access
I write a simple script to test function parameter access. The test case is shown as follows:
#! stap
global filename, flags, mode
probe kernel.function("sys_open") {
filename = $filename;
flags = $flags;
mode = $mode;
}
And I test is in IA32 and IA64 platform, in IA32 I use fedora4, only that Linux kernel version is different and it is 2.6.15-rc1, and gcc versoin is 4.0.0 20050519 (Red Hat 4.0.0-8),and it is default for fedora4. It gets filename value by MACRO fetch_register(0). But from the objdumped file, we can see that it should be from stack because of sys_open is prefixed with asmlinkage flag.
And in ia64 platform, the linux distribution version is RHEL4-U2, gcc version is 3.4.4 20050721 (Red Hat 3.4.4-2). When it boots from system default kernel 2.6.9-22, parameter access result is ok. But when it boots from 2.6.15-rc1 kernel version, the parameter access result is wrong.
Regards
Bibo,mao
>-----Original Message-----
>From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org]
>On Behalf Of Roland McGrath
>Sent: 2005年11月18日 6:12
>To: Mao, Bibo
>Cc: systemtap@sources.redhat.com
>Subject: Re: About function parameter access
>
>Target variable access is driven by the DWARF information emitted by the
>compiler. We have encountered compiler bugs in producing this before, and
>probably will again. You need to file a bug report giving exact details of
>the kernel used and how it was compiled (if it's not a RH-produced RPM),
>so we can investigate.