This patch breaks UML for me on x86-64 running Fedora 8 (gcc 4.1.2):

commit 22eecde2f9034764a3fd095eecfa3adfb8ec9a98
Author: Ingo Molnar <mingo@elte.hu>
Date:   Thu May 1 12:06:54 2008 +0200

    uml: fix gcc problem
    
    this is what caused gcc 4.3 to throw an internal error when
    OPTIMIZE_INLINING was enabled ...
    
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>


If you want to use the option for gcc 4.3 then do it, but only for those
versions.  I haven't tested whether gcc 4.2 and 4.3 works, I just know
that gcc 4.1.2 needs the option for some reason.


Signed-off-by: Ulrich Drepper <drepper@redhat.com>

diff --git a/arch/um/Makefile b/arch/um/Makefile
index 01b97c1..3f52a8c 100644
--- a/arch/um/Makefile
+++ b/arch/um/Makefile
@@ -77,9 +77,9 @@ include $(srctree)/$(ARCH_DIR)/Makefile-os-$(OS)
 KERNEL_DEFINES = $(strip -Derrno=kernel_errno -Dsigprocmask=kernel_sigprocmask \
 			 -Dmktime=kernel_mktime $(ARCH_KERNEL_DEFINES))
 KBUILD_CFLAGS += $(KERNEL_DEFINES)
-# Disable unit-at-a-time mode on pre-gcc-4.0 compilers, it makes gcc use
+# Disable unit-at-a-time mode on pre-gcc-4.3 compilers, it makes gcc use
 # a lot more stack due to the lack of sharing of stacklots:
-KBUILD_CFLAGS += $(shell if [ $(call cc-version) -lt 0400 ] ; then \
+KBUILD_CFLAGS += $(shell if [ $(call cc-version) -lt 0430 ] ; then \
 			echo $(call cc-option,-fno-unit-at-a-time); fi ;)
 
 PHONY += linux
--

Two odd things -
    I'm using what appears to be the same environment - F8, gcc 4.1.2
	gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
and I've seen nothing like this

    --showconfig doesn't work.  This is implemented in
arch/um/kernel/config.c.in (which becomes config.c after some
preprocessing), and as far as I can tell, it's just not in the
binary.  So, I'm wondering whether there's something odd with __used.

	     	 	   Jeff

-- 
Work email - jdike at linux dot intel dot com
--

It breaks things how?

Because on x86, the cut-off is gcc4 vs pre-4. See arch/x86/Makefile:

        KBUILD_CFLAGS += $(shell if [ $(call cc-version) -lt 0400 ] ; then \
                echo $(call cc-option,-fno-unit-at-a-time); fi ;)

and it's a bit distressing that these compiler flags are set two different 
ways (in fact, I was already bothered by the fact that UML sets it totally 
independently of x86 in the first place).

So what is the UML failure behaviour with gcc-4.1.2?

			Linus
--

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


A crash on startup:

Program received signal SIGTERM, Terminated.
0x00000038d6431357 in kill () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc.x86_64
(gdb) bt
#0  0x00000038d6431357 in kill () from /lib64/libc.so.6
#1  0x00000000600201ef in os_dump_core () at arch/um/os-Linux/util.c:92
#2  0x000000006001379f in panic_exit (self=<value optimized out>,
unused1=<value optimized out>, unused2=<value optimized out>)
    at arch/um/kernel/um_arch.c:233
#3  0x00000000600409c5 in notifier_call_chain (nl=<value optimized out>,
val=0, v=0x6022c9c0, nr_to_call=-2, nr_calls=0x0)
    at kernel/notifier.c:85
#4  0x00000000600409f6 in __atomic_notifier_call_chain (nh=0x0, val=15,
v=0x6001e4e1, nr_to_call=-1, nr_calls=0x61c1f6e0)
    at kernel/notifier.c:174
#5  0x0000000060040a07 in atomic_notifier_call_chain (nh=0x0, val=15,
v=0x6001e4e1) at kernel/notifier.c:183
#6  0x000000006002b199 in panic (fmt=0x601989a1 "Attempted to kill
init!") at kernel/panic.c:101
#7  0x000000006002e593 in do_exit (code=11) at kernel/exit.c:965
#8  0x000000006002ec24 in do_group_exit (exit_code=11) at kernel/exit.c:1143
#9  0x0000000060037647 in get_signal_to_deliver (info=0x61c1fa30,
return_ka=0x61c1fab0, regs=0x61c1ca70,
    cookie=<value optimized out>) at kernel/signal.c:1831
#10 0x0000000060011c01 in do_signal () at arch/um/kernel/signal.c:100
#11 0x00000000600135ee in fatal_sigsegv () at arch/um/kernel/trap.c:135
#12 0x0000000060021917 in wait_stub_done (pid=4384) at
arch/um/os-Linux/skas/process.c:94
#13 0x00000000600210a0 in do_syscall_stub (mm_idp=0x61f4fd28,
addr=0x61c1fd18) at arch/um/os-Linux/skas/mem.c:86
#14 0x0000000060021302 in run_syscall_stub (mm_idp=0x61f4fd28,
syscall=154, args=0x61c1fc00, expected=0, addr=0x61c1fd18, done=1)
    at arch/um/os-Linux/skas/mem.c:155
#15 0x0000000060022666 in write_ldt_entry (mm_idp=0x61f4fd28, func=1,
desc=<value optimized out>, addr=0x61c1fd18...
[ message continues ]

It seems that initcalls from the libc side of the house aren't being
called because they're not in the initcall section.  The one that
matters here is init_syscall_regs in arch/um/os-Linux/skas/mem.c.  If
you run with initcall_debug, you'll notice its absence.  As to why,
and why it depends on -fno-unit-at-a-time, I have no idea.

    	   	   Jeff

-- 
Work email - jdike at linux dot intel dot com
--

Can you send me the binary?  Preferably with symbols?

    	     	Jeff

-- 
Work email - jdike at linux dot intel dot com
--

Some UML person should really take a look. It might be a compiler bug that 
is triggered by -fno-unit-at-a-time, but considering that x86 is the most 
tested architecture by far and apparently does *not* hit that problem, it 
sounds more likely that it's UML-related and the compiler just triggers a 
bug in UML.

Anybody?

Yes, I'll revert that commit, but just reverting it without somebody 
trying to figure out what is wrong with UML isn't good.

		Linus
--

I think that's likely true.

  	       	      Jeff

-- 
Work email - jdike at linux dot intel dot com
--

And btw, a revert is what I'm going to do, not just bump the gcc version 
up as in Uli's patch. As mentioned, if it was about gcc versions, matching 
the x86 choice should have been the much better tested one than picking 
another version at random.

		Linus
--