|
Bugzilla – Full Text Bug Listing |
| Summary: | gcc4 miscompiles cpuburn | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Andreas Klein <asklein> |
| Component: | Kernel | Assignee: | Gerd Hoffmann <kraxel> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | matz, vetter |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Andreas Klein
2005-10-14 16:51:54 UTC
Its assembler only, so how can it be miscompiled? can you get gdb backtrace or similar? gdb doesn't help. pluto:/tmp/cpuburn-1.4 # gdb ./burnP6 GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-suse-linux"...(no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run Starting program: /tmp/cpuburn-1.4/burnP6 Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. You can't do that without a process to debug. (gdb) bt No stack. (gdb) Problem is not GCC, but the source, or if at all then the dynamic loader. The sources don't specify a .data segment (it has some read-only data in the .text segment). The old binutils on 9.3 created an empty .data and .bss section, with an according LOAD segment (so the final executable has two). The new binutils don't create this empty .data which isn't specified in the source, so the executable there only has one LOAD segment. This seems to confuse the dynamic loader which segfaults. I will reassign this to the binutils maintainer who additional has insight in the dynamic loader, he should determine if such executable is allowed and hence either fix binutils or ld.so, or declare this as WONTFIX. Hmm, I forgot to mention that this problem can be worked around in the source
by simply adding a .data section by applying this patch:
--- burnP6.S.orig 2005-11-07 16:06:55.000000000 +0100
+++ burnP6.S 2005-11-07 16:01:28.000000000 +0100
@@ -69,6 +69,7 @@ int_exit: # error abort
push %eax # *BSD syscall
int $0x80
#endif
+.data
.align 32,0
half: .long 0x7fffffff,0
e: .long 0xffffffff,0x3fdfffff
Neither binutils nor glibc has anything to do with this. In a statically linked binary the dynamic linker does not come into play at all. It's the kernel that refuses to execute.
$ strace ./burnP6
execve("./burnP6", ["./burnP6"], [/* 113 vars */]) = -1 EFAULT (Bad address)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Um, right. It's a static binary. Don't know what I was thinking ;) This is an issue with the ELF loader - is it legal to have an ELF binary without DATA and BSS segments? If so, the ELF loader needs fixing. Anyone willing to pick this up? Kraxel? Yes, this is a legal ELF file. We didn't create such files in the past, but the new binutils will do so. Probably we need that one: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6de505173e24e76bb33a2595312e0c2b44d49e58 Can you try a kernel-of-the-day from ftp://ftp.suse.com/pub/projects/kernel/kotd/i386/HEAD/? If my guess from comment #10 is correct it should be fixed in those kernels already. Ok, tested, it's the correct fix, committed to kernel cvs, SL100 branch. |