About function parameter access

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

About function parameter access

bibo,mao-2
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
Reply | Threaded
Open this post in threaded view
|

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.
Reply | Threaded
Open this post in threaded view
|

RE: About function parameter access

bibo,mao-2
In reply to this post by bibo,mao-2
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: [hidden email] [mailto:[hidden email]]
>On Behalf Of Roland McGrath
>Sent: 2005年11月18日 6:12
>To: Mao, Bibo
>Cc: [hidden email]
>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.
Reply | Threaded
Open this post in threaded view
|

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