This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
BUG in 2.95.3 - wrong asm code provokes an input variable to be nullified
- To: gcc-bugs at gcc dot gnu dot org
- Subject: BUG in 2.95.3 - wrong asm code provokes an input variable to be nullified
- From: Maxime Austruy <maxime at vmware dot com>
- Date: Thu, 14 Jun 2001 17:57:54 -0700
In certain conditions (still not clear) gcc overwrites a parameter
given to a function. The attached file is the preprocessed (ready
to be compiled) file which generates the error.
If we disassembled the function...
(gdb) disass FaultyFunction
Dump of assembler code for function FaultyFunction:
0x13e30 <FaultyFunction>: push %ebp
0x13e31 <FaultyFunction+1>: mov %esp,%ebp
0x13e33 <FaultyFunction+3>: sub $0x17c,%esp
0x13e39 <FaultyFunction+9>: push %edi
0x13e3a <FaultyFunction+10>: push %esi
0x13e3b <FaultyFunction+11>: push %ebx
0x13e3c <FaultyFunction+12>: mov $0x22764,%edx
0x13e41 <FaultyFunction+17>: call 0x13e42
<FaultyFunction+18>
0x13e46 <FaultyFunction+22>: mov 0xc(%ebp),%edi
0x13e49 <FaultyFunction+25>: mov 0x10(%ebp),%ebx
0x13e4c <FaultyFunction+28>: mov 0x14(%ebp),%eax // ?
0x13e4f <FaultyFunction+31>: xor %edx,%edx // XXX
0x13e51 <FaultyFunction+33>: mov %eax,0x14(%ebp) // ?
0x13e54 <FaultyFunction+36>: mov %edx,0x18(%ebp) // XXX
A part of this code is generic to all the functions. We see that the
processor clears edx, then put it into ebp[0x18] which corresponds to
the address of the fifth input variable, M. And this looks like a bug.
Apart from this, it generates some weird unusefull instructions,
like just putting a value from memory to eax, and then restoring this
same information to memory.
/******************************************************************/
Here's the .S file generated when we compile using -S -g3 -O2
[...]
.text
.align 4
.stabs "FaultyFunction:F(0,19)",36,0,3433,FaultyFunction
.stabs "s1:p(34,32)",160,0,3428,8
.stabs "s2:p(34,32)",160,0,3429,12
.stabs "m1:p(53,7)",160,0,3430,16
.stabs "m2:p(53,7)",160,0,3431,20
.stabs "M:p(53,7)",160,0,3432,24
.globl FaultyFunction
.type FaultyFunction,@function
FaultyFunction:
.LBB189:
pushl %ebp
movl %esp,%ebp
subl $380,%esp
pushl %edi
pushl %esi
pushl %ebx
.data
.align 4
.LP100:
.long 0
.text
movl $.LP100,%edx
call mcount
.stabn 68,0,3433,.LM1059-FaultyFunction
.LM1059:
movl 12(%ebp),%edi
movl 16(%ebp),%ebx
movl 20(%ebp),%eax // ??
xorl %edx,%edx // XXX
movl %eax,20(%ebp) // ??
movl %edx,24(%ebp) // XXX
[...]
------------------------------------
[maustruy@valhalla vmx]$ gcc -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs
gcc version 2.95.3 20010315 (release)
------------------------------------
(I use the RPM of gcc 2.95.3 from PLD)
If this is a known issue and a workaround exists, please let me know!
Thanks,
Maxime
ps: you have to compile the attached file with -O2 for the bug to
appear.
with gcc 2.7.2.3, everything is fine....
#include <stdio.h>
typedef unsigned long long uint64;
typedef char Bool;
typedef struct Params {
unsigned int hw;
} Params;
/*************************************************************************/
Bool f2(const char *chaine,
unsigned int c, unsigned int h, unsigned int s,
uint64 size,
Params *dp) {
return 1;
}
void f3(const char *s,
uint64 *i0,
unsigned int *i1,
unsigned int *i2,
unsigned int *i3) {
}
unsigned int
f4(int i, const char *s) {
return 0;
}
Params *
f5(void) {
return NULL;
}
Bool
test_gcc_bug(char const *s1,
char const *s2,
int hc,
int lc,
int testVar)
{
Params p;
Bool st;
uint64 cpct;
unsigned int c;
unsigned int h;
unsigned int s;
unsigned int v;
v = f4(1, "test?");
p.hw = v;
cpct = ((uint64)((unsigned int )hc) << 32) | (unsigned int )lc;
f3(s2, &cpct, &c, &h, &s);
st = f2(s1,
c, h, s,
cpct / 512,
&p);
if (testVar == 0) {
printf("Buggy compiler. (%d)\n", testVar);
exit(-1);
} else {
printf("Compiler OK.\n");
exit(1);
}
return 1;
}
int main(void) {
test_gcc_bug("dummy string 1", "dummy string 2", 1, 2, 3);
return 0;
}