[PATCH] fix UML on x86-64 - Kernel

This is a discussion on [PATCH] fix UML on x86-64 - Kernel ; This patch breaks UML for me on x86-64 running Fedora 8 (gcc 4.1.2): commit 22eecde2f9034764a3fd095eecfa3adfb8ec9a98 Author: Ingo Molnar 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 ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: [PATCH] fix UML on x86-64

  1. [PATCH] fix UML on x86-64

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

    commit 22eecde2f9034764a3fd095eecfa3adfb8ec9a98
    Author: Ingo Molnar
    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
    Signed-off-by: Thomas Gleixner


    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

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH] fix UML on x86-64



    On Tue, 6 May 2008, Ulrich Drepper wrote:
    >
    > This patch breaks UML for me on x86-64 running Fedora 8 (gcc 4.1.2):


    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH] fix UML on x86-64

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

    Linus Torvalds wrote:
    > It breaks things how?


    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=,
    unused1=, unused2=)
    at arch/um/kernel/um_arch.c:233
    #3 0x00000000600409c5 in notifier_call_chain (nl=,
    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=) 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=, addr=0x61c1fd18, done=1)
    at arch/um/sys-x86_64/../sys-i386/ldt.c:72
    #16 0x00000000600228b4 in init_new_ldt (new_mm=0x61f4fd28,
    from_mm=)
    at arch/um/sys-x86_64/../sys-i386/ldt.c:425
    #17 0x0000000060013b6c in init_new_context (task=,
    mm=) at arch/um/kernel/skas/mmu.c:87
    #18 0x000000006006d66e in bprm_mm_init (bprm=0x61c62dc0) at fs/exec.c:346
    #19 0x000000006006e33a in do_execve (filename=0x60191c1c "/bin/sh",
    argv=0x601c6440, envp=0x601c6020, regs=0x61c1ca70)
    at fs/exec.c:1287
    #20 0x000000006000fe2f in execve1 (file=0x0, argv=0xf, env=0x6001e4e1)
    at arch/um/kernel/exec.c:62
    #21 0x000000006000fea7 in um_execve (file=0x0, argv=0xf, env=0x6001e4e1)
    at arch/um/kernel/exec.c:78
    #22 0x0000000060011f28 in kernel_execve (filename=0x0, argv=0xf,
    envp=0x6001e4e1) at arch/um/kernel/syscall.c:129
    #23 0x000000006000fbf2 in run_init_process (init_filename=0x0) at
    init/main.c:789
    #24 0x000000006000fcc7 in init_post () at init/main.c:831
    #25 0x0000000060001546 in kernel_init (unused=) at
    init/main.c:884
    #26 0x000000006001e5e1 in run_kernel_thread (fn=0x6000139c
    , arg=0x0, jmp_ptr=)
    at arch/um/os-Linux/process.c:267
    #27 0x0000000060011094 in new_thread_handler () at
    arch/um/kernel/process.c:151
    #28 0x0000000000000000 in ?? ()


    - --
    ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (GNU/Linux)

    iD8DBQFIIOwN2ijCOnn/RHQRAqIbAJ48M4xgOGBOWaKdNcWIl7ZENJaYEQCfccJM
    OS7U3mc48z4UpodpagTwt2M=
    =Fv45
    -----END PGP SIGNATURE-----
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [PATCH] fix UML on x86-64



    On Tue, 6 May 2008, Ulrich Drepper wrote:
    >
    > Linus Torvalds wrote:
    > > It breaks things how?

    >
    > A crash on startup:


    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [PATCH] fix UML on x86-64



    On Tue, 6 May 2008, Linus Torvalds wrote:
    >
    > Yes, I'll revert that commit


    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [PATCH] fix UML on x86-64

    On Tue, May 06, 2008 at 04:38:54PM -0700, Ulrich Drepper wrote:
    > Linus Torvalds wrote:
    > > It breaks things how?

    >
    > A crash on startup:
    >
    > #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


    Can you send me the binary? Preferably with symbols?

    Jeff

    --
    Work email - jdike at linux dot intel dot com
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [PATCH] fix UML on x86-64

    On Tue, May 06, 2008 at 05:06:40PM -0700, Linus Torvalds wrote:
    > 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?


    I think that's likely true.

    Jeff

    --
    Work email - jdike at linux dot intel dot com
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [uml-devel] [PATCH] fix UML on x86-64

    On Tue, May 06, 2008 at 04:38:54PM -0700, Ulrich Drepper wrote:
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > Linus Torvalds wrote:
    > > It breaks things how?

    >
    > A crash on startup:


    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [uml-devel] [PATCH] fix UML on x86-64

    On Tue, May 06, 2008 at 07:04:43PM -0400, Ulrich Drepper wrote:
    > This patch breaks UML for me on x86-64 running Fedora 8 (gcc 4.1.2):


    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread