Bug 57889 - gcc -Ox produces bad startup code with -gx on AMD TBird
gcc -Ox produces bad startup code with -gx on AMD TBird
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: gcc (Show other bugs)
7.0
athlon Linux
high Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-12-30 19:55 EST by Landon Curt Noll
Modified: 2005-10-31 17:00 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-12-31 16:56:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Landon Curt Noll 2001-12-30 19:55:31 EST
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 05:29:01 EST
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 14:57:09 EST
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 15:01:42 EST
> 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 15:12:13 EST
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 16:56:44 EST
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 08:08:59 EDT
Calc works with readline and -g3 and -O3 under RH7.3.

Note You need to log in before you can comment on or make changes to this bug.