About function parameter access

About function parameter access

[Mao, Bibo]

Hi all,
I find that there maybe exists one problem when accessing function
parameter. From the translated script, we can see that it uses MACRO
fetch_register to parameter value. Always in IA32 the first parameter is
placed in EAX register, and the macro is  fetch_register(0).

But when function is with asmlinkage prefix, it is stored in stack, but
not in register. Maybe it the same reason with what has been reported
as: http://sourceware.org/bugzilla/show_bug.cgi?id=1868

And I has tested systemtap.samples/sysopen.stp, this function is
prefixed with asmlinkage, filename parameter is accessed by MACRO
fetch_register(0).

Regards
Bibo,mao

Re: About function parameter access

[Roland McGrath]

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.

RE: About function parameter access

[Mao, Bibo]

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.

RE: About function parameter access

[Roland McGrath]

Sorry I was not sufficiently clear on the information required to respond
usefully to your report.  Since you have built your own kernels and only
have problems with those, I need to have the complete kernel binaries and
the complete recipe for reproducing them from the source exactly as you
have done.  Now I know what compiler to use, but that is only the first
piece of information I need.

Before putting effort into that, you should try the newest FC4 update
compiler, which is gcc-4.0.1-4.fc4; it may already have fixed some
problems.  But please note that so far I don't know whether there is any
compiler problem here at all.  I need to examine the complete kernel
binaries with their debuginfo to determine if the problem is with the
compiler producing the info or with systemtap reading it.

For the RHEL4-U2 ia64 compiler, I don't think there is a newer update of
that gcc to try.  So I just need to see the full kernel binary first thing.


Thanks,
Roland