Re: [Fastboot] Re: [-mm patch] i386: enable REGPARM by default

[Vivek Goyal]

On Tue, Jun 28, 2005 at 09:59:36PM +0200, Mark Kettenis wrote:
>    Date: Tue, 28 Jun 2005 16:54:12 +0530
>    From: Vivek Goyal <vgoyal@xxxxxxxxxx>
> 
>    > Thanks. Any idea what might be amiss with my case where I am not seeing 
>    > proper function parameter values while analyzing kdump generated crash
>    > dump with gdb. I am using following gdb and gcc versions.
>    > 
>    > GNU gdb Red Hat Linux (6.1post-1.20040607.62rh)
>    > gcc (GCC) 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)
>    > 
> 
>    Some more info. I dumped the stack contents and it seems that stack is fine 
>    and parameters are intact on stack. So now it seems to be a matter of 
>    how gdb is interpreting the stack contents. Any guess, what the problem is?
> 
> I'd say the problem is with a user building stuff with non-standard
> "optimizations", probably even stripping his executable, and expecting
> to be able to debug the result.
> 
>    Why func2() and func1() are not showing right parameter values. 
> 


In this case I am building linux kernel with debug info (-g) and -mregparm
is not specified. So parameters should be passed on stack. Following
is the effective command line to build kernel/sysfs.c. I am not sure if
any of the below mentioned options are going to affect the gdb results.

  gcc -m32 -Wp,-MD,kernel/.ksysfs.o.d  -nostdinc -isystem /usr/lib/gcc/i386-redhat-linux/3.4.3/include -D__KERNEL__ -Iinclude  -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -ffreestanding -O2     -fomit-frame-pointer -g -pipe -msoft-float -mpreferred-stack-boundary=2 -fno-unit-at-a-time -march=i686 -mtune=pentium4 -Iinclude/asm-i386/mach-default -Wdeclaration-after-statement     -DKBUILD_BASENAME=ksysfs -DKBUILD_MODNAME=ksysfs -c -o kernel/ksysfs.o kernel/ksysfs.c


> Repeating what Daniel said before, by using "regparm", function
> arguments are now passed in registers instead of on the stack.  It's
> extremely unlikely that these function arguments will stay in those
> registers for ever, especially since you've only got a handfull of
> them on the i386.  

Sorry for the confusion. In the last mail all the results were reported
with REGPARM disabled. I wanted to make sure that first normal case works
fine and then discuss the REGPARM case later.


> So eventually they will be moved to some other
> register or, more likely, to memory.  If the compiler doesn't tell gdb
> about it, gdb will still think the value is in the register, and
> display whatever what's there now, which is likely to be the wrong
> value.  There are two ways the compiler can tell gdb where things are:
> 
> 1. By explicitly specifying the new location.  Both DWARF 2 and stabs
>    debugging formats can do this, but AFAIK, GCC won't do this if a
>    register is spilled to the stack.
> 
> 2. By specifying where registers are saved.  Only DWARF 2 can do this.
> 
> We've seen cases where the information generated by GCC for 1 or 2 is
> either incomplete or wrong.  There also have been cases where GDB
> didn't interpret that information correctly.  And then some people
> tend to remove some of the debug information by stripping their code
> or using broken linker scripts. You'll need to find out where the
> problem is, but my bet is that its's a problem with GCC since you make
> it generate non-standard code.

Ok. I will try to figure out where the problem is. Time to jump into gcc
and gdb code. :-)

Thanks
Vivek
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/