Old gcc method parameter error

Old gcc method parameter error

[Fabian Cenedese]

Hi

I have a problem with an old gcc 2.95.2. Before you say that I should update
I can tell you that we have a new gcc4.5 based toolchain. But we still need
to support existing projects that work with the old compiler.

This is a cross-compiled gcc for PowerPC-EABI (e.g. 603, 750 etc)

The problem is with the way the parameters are placed on the stack if there's
not enough space in the registers (r3-r10, f1-f8).

unsigned long MyClass::Func(unsigned long a1, unsigned long a2, unsigned long a3, unsigned long a4,
	unsigned long a5, unsigned long a6, unsigned long a7, unsigned long a8, double d, char* s)
{
	printf("Received string: '%s'.", s);
	return 0;
}

void MyClass::Func2()
{
	Func(1, 2, 3, 4, 5, 6, 7, 8, 9.9, "testing");
}

I'd expect that r3 would hold the 'this' pointer, r4-r10 would hold the first
seven arguments, f1 would hold the double value and a8 and the string
pointer would be passed on the stack as two consecutive values
(e.g. x+8 and x+12, x is some offset in the stack).

The problem is now that the caller exactly does the described thing,
but the called function expects a different layout on the stack. The
string pointer is read from x+16 where of course no useful value is
stored. It's as if it thinks that at x+12 should be the double value
which makes no sense as this would need 8 bytes anyway. If I take
out the double value from the argument list then the two values are
as expected.

This function and the call are in the same file so any compiler flag
(calling convention) would apply to both places.

Does this ring a bell? I already tried to look at the diff to gcc 2.95.3
to find if this may have been solved but I couldn't understand the
gcc internal termini. I can understand if nobody has interest in
compiler archeology but I thought I'd ask anyway.

Thanks

bye  Fabi

Re: Old gcc method parameter error

[Ian Lance Taylor]

Fabian Cenedese <Cenedese@indel.ch> writes:

> The problem is with the way the parameters are placed on the stack if there's
> not enough space in the registers (r3-r10, f1-f8).
>
> unsigned long MyClass::Func(unsigned long a1, unsigned long a2, unsigned long a3, unsigned long a4,
> 	unsigned long a5, unsigned long a6, unsigned long a7, unsigned long a8, double d, char* s)
> {
> 	printf("Received string: '%s'.", s);
> 	return 0;
> }
>
> void MyClass::Func2()
> {
> 	Func(1, 2, 3, 4, 5, 6, 7, 8, 9.9, "testing");
> }
>
> I'd expect that r3 would hold the 'this' pointer, r4-r10 would hold the first
> seven arguments, f1 would hold the double value and a8 and the string
> pointer would be passed on the stack as two consecutive values
> (e.g. x+8 and x+12, x is some offset in the stack).

My guess would be that gcc 2.95.2 has a bug when some arguments that are
placed in registers follow some arguments that are placed on the stack.
The PPC EABI is unusual in permitting that to happen.  That bug could
have been fixed any time in the last 10 years.  It would probably be a
change to gcc/function.c or gcc/calls.c.

Ian

Re: Old gcc method parameter error

[Gunther Nikl]

Fabian Cenedese wrote:
> I have a problem with an old gcc 2.95.2.

If you really need GCC 2.95, then you should use the latest version
from the GCC 2.95 CVS branch.

> Before you say that I should update I can tell you that we have
> a new gcc4.5 based toolchain. But we still need to support existing
> projects that work with the old compiler.

But if the old compiler has a bug, what are you going to do? And what
you are describe later seems to be a bug of GCC 2.95.2/2.95.3.

> This is a cross-compiled gcc for PowerPC-EABI (e.g. 603, 750 etc)
> 
> The problem is with the way the parameters are placed on the stack if there's
> not enough space in the registers (r3-r10, f1-f8).
> 
> unsigned long MyClass::Func(unsigned long a1, unsigned long a2, unsigned long a3, unsigned long a4,
> 	unsigned long a5, unsigned long a6, unsigned long a7, unsigned long a8, double d, char* s)
> {
> 	printf("Received string: '%s'.", s);
> 	return 0;
> }
> 
> void MyClass::Func2()
> {
> 	Func(1, 2, 3, 4, 5, 6, 7, 8, 9.9, "testing");
> }

FWIW, GCC 4.5.0 complained the string argument.

> I'd expect that r3 would hold the 'this' pointer, r4-r10 would hold the first
> seven arguments, f1 would hold the double value and a8 and the string
> pointer would be passed on the stack as two consecutive values
> (e.g. x+8 and x+12, x is some offset in the stack).
> 
> The problem is now that the caller exactly does the described thing,
> but the called function expects a different layout on the stack. The
> string pointer is read from x+16 where of course no useful value is
> stored. It's as if it thinks that at x+12 should be the double value
> which makes no sense as this would need 8 bytes anyway. If I take
> out the double value from the argument list then the two values are
> as expected.
> 
> This function and the call are in the same file so any compiler flag
> (calling convention) would apply to both places.
> 
> Does this ring a bell? I already tried to look at the diff to gcc 2.95.3
> to find if this may have been solved but I couldn't understand the
> gcc internal termini. I can understand if nobody has interest in
> compiler archeology but I thought I'd ask anyway.

I am in no way a PPC expert, but AFAICT it seems to me that GCC
2.95.2/GCC 2.95.3 had a bug with argument passing and it looks
like that the bug is fixed with 2.95.4 (from the CVS branch of
GCC 2.95):

@@ -25,7 +25,7 @@
 	stfd 1,40(31)
 	lis 9,.LC0@ha
 	la 3,.LC0@l(9)
-	lwz 4,80(31)
+	lwz 4,76(31)
 	crxor 6,6,6
 	bl printf
 	li 3,0
@@ -139,4 +139,4 @@
 	blr
 .Lfe3:
 	.size	 Func2__7MyClass,.Lfe3-Func2__7MyClass
-	.ident	"GCC: (GNU) 2.95.2 19991024 (release)"
+	.ident	"GCC: (GNU) 2.95.4 20020320 (prerelease)"


Regards,
Gunther

Re: Old gcc method parameter error

[Fabian Cenedese]

At 21:19 30.09.2011 +0200, Gunther Nikl wrote:
>Fabian Cenedese wrote:
>> I have a problem with an old gcc 2.95.2.
>
>If you really need GCC 2.95, then you should use the latest version
>from the GCC 2.95 CVS branch.

Didn't know that existed, I thought 2.x was shelved long ago.

>> Before you say that I should update I can tell you that we have
>> a new gcc4.5 based toolchain. But we still need to support existing
>> projects that work with the old compiler.
>
>But if the old compiler has a bug, what are you going to do? And what
>you are describe later seems to be a bug of GCC 2.95.2/2.95.3.

2.95.3 or 2.94.4 still counts as old, so there shouldn't be a problem to
update to these versions or backport some fixes.

>> The problem is now that the caller exactly does the described thing,
>> but the called function expects a different layout on the stack. The
>> string pointer is read from x+16 where of course no useful value is
>> stored. It's as if it thinks that at x+12 should be the double value
>> which makes no sense as this would need 8 bytes anyway. If I take
>> out the double value from the argument list then the two values are
>> as expected.
>> 
>> Does this ring a bell? I already tried to look at the diff to gcc 2.95.3
>> to find if this may have been solved but I couldn't understand the
>> gcc internal termini. I can understand if nobody has interest in
>> compiler archeology but I thought I'd ask anyway.
>
>I am in no way a PPC expert, but AFAICT it seems to me that GCC
>2.95.2/GCC 2.95.3 had a bug with argument passing and it looks
>like that the bug is fixed with 2.95.4 (from the CVS branch of
>GCC 2.95):

Thanks a lot for this hint.

bye  Fabi

Re: Old gcc method parameter error

[Gunther Nikl]

Ian Lance Taylor wrote:
> Gunther Nikl <gnikl@users.sourceforge.net> writes:
> 
>> I am in no way a PPC expert, but AFAICT it seems to me that GCC
>> 2.95.2/GCC 2.95.3 had a bug with argument passing and it looks
>> like that the bug is fixed with 2.95.4 (from the CVS branch of
>> GCC 2.95):
> 
> Interesting.  That suggests that you need a patch like this one
> 
> http://gcc.gnu.org/ml/gcc-patches/1999-11n/msg00616.html
> 
> See revision 41152 in the SVN repository.

Indeed, that patch is the fix for the described problem.