Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 57889

Summary:	gcc -Ox produces bad startup code with -gx on AMD TBird
Product:	[Retired] Red Hat Linux	Reporter:	Landon Curt Noll <redhat-mail>
Component:	gcc	Assignee:	Jakub Jelinek <jakub>
Status:	CLOSED NOTABUG	QA Contact:	Brian Brock <bbrock>
Severity:	high	Docs Contact:
Priority:	high
Version:	7.0
Target Milestone:	---
Target Release:	---
Hardware:	athlon
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-12-31 21:56:49 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Landon Curt Noll 2001-12-31 00:55:31 UTC

From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.2.19-7.0.12 i686)

Description of problem:
Using gcc-2.96-85, compiling with the gcc optimizer (i.e., -O, -O2, or -O3)
AND generating debugging information (i.e., -g or -g3) produces bad startup
code, whereas using just the optimizer alone or generating debug symbols
alone is just fine. The bad startup code causes programs to Seg fault in
startup code, prior to main.

Version-Release number of selected component (if applicable):
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85)

How reproducible:
Always

Steps to Reproduce:
0.Use an AMD TBird CPU system (say on a SOYO Dragon motherboard)
1.fetch calc from http://www.isthe.com/chongo/src/calc/gcc-calc-bug.tar.gz
2.tar -zxvf gcc-calc-bug.tar
3.cd calc-2.11.5.5
4.make calc	(observe that calc compiles with -O2)
5. ./calc 2+2	(observe that calc says 4 and exits)
6.make clobber
7.make calc DEBUG="-O -g"		(observe that calc compiles with -O -g)
8. ./calc 2+2	(observe that calc dumps core, prior to running main)
	

Actual Results:  Calc produces a segmentation fault early in startup when
compiled with -O -g:

$ ./calc
Segmentation fault (core dumped)

$ gdb ./calc core
...
Core was generated by `./calc'.
Program terminated with signal 11, Segmentation fault.
#0  0x2aab68a0 in ?? ()
(gdb) where
#0  0x2aab68a0 in ?? ()
#1  0x2aaadaf5 in ?? ()
#2  0x2aabb197 in ?? ()
#3  0x2aaad441 in ?? ()
#4  0x2aaad233 in ?? ()
(gdb) break main
Breakpoint 1 at 0x8049b89: file calc.c, line 100.
(gdb) run
Starting program: /usr/local/src/cmd/calc/./calc 

Program received signal SIGSEGV, Segmentation fault.
0x2aab68a0 in ?? ()

when performed on an AMD TBird CPU.

NOTE: In the above gdb example, when calc was rerun, it died in the startup
          code prior to main.


Expected Results:  calc should not SEG fault in startup code prior to main.
Use of -g or -g3 should not cause a program to dump core.

Additional info:

On AMD Althlon, non-TBird CPUs (CPUs without the 3DNow features)
the -Ox -gx startup bug does not show up.  It seems that one must
be using the AMD Athlon Thunderbird CPU line to run into this bug.

A simple "Hello, world" program does not trigger this bug, it seems that
one must have a larger program with lots of symbols and what-nots on
an AMD TBird to trigger this program ... otherwise I'd give you a smaller
bug example.  :-) :-(

FYI: I'm using glibc-2.2.4-18.7.0.3

I'm running on a SOYO Dragon board with an AMD 1.4 GHz CPU.

This bug appears under RH7.0 as well.

Comment 1 Jakub Jelinek 2001-12-31 10:29:01 UTC

Cannot reproduce this either. Are you sure your hardware is ok?
Can you try using an .i686.rpm kernel instead of .athlon.rpm one
(or use noathlon).

Comment 2 Landon Curt Noll 2001-12-31 19:57:09 UTC

Did you try it under RH7.0 or RH7.1 (with the latest RPM patches)?
On RH7.0 for example the kernel was built with these processor
type and features:

CONFIG_M686=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
# CONFIG_1GB is not set
CONFIG_2GB=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_SMP is not set

What sort of CPU were you using?  Here is the /proc/cpuinfo for a system
on which -O -g dies in startup:

processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 6
model		: 4
model name	: AMD Athlon(tm) processor
stepping	: 4
cpu MHz		: 1396.557
cache size	: 256 KB
fdiv_bug	: no
hlt_bug		: no
sep_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 psn
mmxext mmx fxsr 3dnowext 3dnow
bogomips	: 2785.28

How does that compare with the system on which you tested?

Here is a /proc/cpuinfo on a non-TBird CPU for which -O -g does NOT
fail in startup:

processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 6
model		: 2
model name	: AMD Athlon(tm) Processor
stepping	: 1
cpu MHz		: 598.841
cache size	: 512 KB
fdiv_bug	: no
hlt_bug		: no
sep_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36
mmxext mmx fxsr 3dnowext 3dnow
bogomips	: 1192.75

Both are running:

gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85)
glibc-profile-2.2.4-18.7.0.3
glib-devel-1.2.8-4
compat-glibc-6.2-2.1.3.2
glib10-1.0.6-9
glibc-devel-2.2.4-18.7.0.3
glibc-common-2.2.4-18.7.0.3
glib-1.2.8-4
glibc-2.2.4-18.7.0.3
gcc-c++-2.96-85
kgcc-1.1.2-40
gcc-2.96-85
gcc-objc-2.96-85
gcc-g77-2.96-85

Does that help?

Comment 3 Landon Curt Noll 2001-12-31 20:01:42 UTC

> Are you sure your hardware is ok?

The hardware tests are clean.  I have had no crashes or CPU
lockups.   Ran CPU and disk heavy jobs for extended periods
of time without any problems being detected (computational-wise
or system crash/lockup-wise)

> Can you try using an .i686.rpm kernel instead of .athlon.rpm one
> (or use noathlon).

I'm using kernel-2.2.19-7.0.12 with the CPU/Processor options
as shown in the previous posting.

Comment 4 Landon Curt Noll 2001-12-31 20:12:13 UTC

FYI: The same -O -g bug shows up under a 2.2.19-7.0.10 kernel ...

Comment 5 Landon Curt Noll 2001-12-31 21:56:44 UTC

The bug seems to be triggered by use of readline. If calc is compiled without
readline, all is OK and calc does not dump core prior to main.  If calc is
compiled
with readline, then calc dumps core in startup.

Take a look at this tarball:

	http://www.isthe.com/chongo/src/calc/gcc-readline-calc-bug.tar.gz

The Makefile in the gcc-readline-calc-bug.tar.gz file has been changed to
compile with readline.  I also changed the default compile to use '-O -g".
The calc binary was compiled under RH7.0 with:

(I did a rpm -q -a | egrep 'gcc|libc|readline|curses' which printed out a
few more RPMs that needed, but you should get the idea)

ncurses-5.2-2
libc-5.3.12-31
gcc-2.96-85
glibc-common-2.2.4-18.7.0.3
readline-4.1-5
ncurses-devel-5.2-2
gcc-g77-2.96-85
gcc-c++-2.96-85
compat-glibc-6.2-2.1.3.2
ncurses4-5.0-2
readline2.2.1-2.2.1-2
glibc-2.2.4-18.7.0.3
glibc-profile-2.2.4-18.7.0.3
readline-devel-4.1-5
kgcc-1.1.2-40
gcc-objc-2.96-85
glibc-devel-2.2.4-18.7.0.3

on a 2.2.19-7.0.12 kernel.

The core dump in that tarball shows the effect of the pre-main seg fault.

=-=

It is interesting to note that under the RH7.0 stock CD, this bug does
not show up.  Something that was updated (kernel? glibc? gcc?) changed
the behaviour of calc when compiled with -O -g.

Ideas?

Comment 6 Landon Curt Noll 2002-10-09 12:08:59 UTC

Calc works with readline and -g3 and -O3 under RH7.3.