From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 Description of problem: In certain leaf functions, the code generated by gcc does not allocate a new stack frame, i.e. it does not subtract from %esp in the function prelude, yet the remainder of the code accesses stack-allocated local variables (at negative offsets w.r.t %ebp). This results in accesses to stack locations below the stack pointer %esp. These locations can be wiped at any time by a signal handler, causing the program to crash. Also, this can invalidate the stack growing heuristic in the kernel, causing the program to be killed on a segmentation violation. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Compile the attached md5.c file with "gcc -O -S" 2. Look at md5.s, function MD5Transform, and notice the lack of a "subl $NNN, %esp" instruction in the prelude, and the accesses " movl %eax, -16(%ebp)" later in the code. Additional info: This is the same bug as #55568, but with a much smaller code fragment to reproduce it.
Created attachment 41168 [details] excerpt from Colin Plumb's MD5 implementation demonstrating wrong generated code
We also ran into this bug when compiling the SHA1 code in the Network Security Services (NSS) libraries on Red Hat Linux 7.2. See http://bugzilla.mozilla.org/show_bug.cgi?id=116327 The code generated by gcc 2.96-81 on Red Hat Linux 7.1 is good. I will attach an excerpt of the SHA1 code in NSS.
Created attachment 41207 [details] excerpt from NSS 3.3.2's SHA1 implementation demonstrating wrong generated code
Created attachment 41208 [details] diffs between the assembler files generated by 'gcc -S -O2 -fPIC sha1.c' on 7.1 and 7.2
Should be fixed in gcc-2.96-103, currently at: ftp://people.redhat.com/jakub/gcc/2.96-103/
Jakub, This is good news. Thanks. We will need to wait for an official Red Hat Linux 7.2 update that includes this fix though. Do you know when that will be available?
I verified that gcc 2.96-103 generates the same code from my sha1.c test case as gcc 2.96-81.
So this is not fixed?
This is fixed. gcc 2.96-81 and gcc 2.96-103 generate the correct code. It's 2.96-98 (the gcc in Red Hat Linux 7.2) that has the bug.
OK, then the bug is fixed.