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: 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.


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