RE: Repost: Inaccurate function parameter location in debug info with gcc 3.x and 4.0

["Mao, Bibo" <bibo dot mao at intel dot com>]

There are two different function probe point, one is function entry point, and the other is prologue end point. Function parameter location is different between these two probe points.
Currrently systemtap uses prologue end point as function probe point, there is one test case sysopen.stp, you can check translated c file, and the probe point value about sys_open is different with that in file/proc/kallsyms.

Bibo,mao

>-----Original Message-----
>From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org]
>On Behalf Of Yi Feng
>Sent: 2006年5月16日 1:55
>To: systemtap@sources.redhat.com
>Subject: Repost: Inaccurate function parameter location in debug info with gcc
>3.x and 4.0
>
>This is a repost. I wonder if anybody tried compiling the kernel with
>gcc 3.x and noticed the same problem. Thanks very much!
>
>
>Hi,
>
>I have encountered a problem with the DWARF debug info when compiling
>the kernel with gcc 3.x and 4.0 with optimization flags of either -O1
>or -O2. When looking at the parameter locations of, for example,
>sys_read, the debug info says they are all in EAX while these
>parameters are in fact only read into EAX temporarily in the function
>body. Using this inaccurate information, SystemTap looks at EAX at the
>function entry when it's told to instrument the function parameters.
>Obviously the returned value is bogus.
>
>I'm wondering if people have noticed this problem before. Using gcc
>3.x/4.0 with -Os or gcc 4.1 (with either -O2 or -Os) would generate
>accurate debug info which gives the correct stack locations of the
>parameters. Therefore SystemTap works correctly to get the parameter value.
>
>This happens with all the 2.6.1x kernels I've tested. Thanks very much
>for any information you may have.
>
>
>Yi Feng