From: Rob L. <ro...@la...> - 2005-11-13 01:37:00
|
I needed to patch two things to get 2.6.15-rc1 to build on an x86-64 system running PLD linux: diff -ru linux-2.6.15-rc1/arch/um/Kconfig.x86_64 linux-2.6.15-rc1-new/arch/um/Kconfig.x86_64 --- linux-2.6.15-rc1/arch/um/Kconfig.x86_64 2005-11-13 02:08:34.318108152 +0100 +++ linux-2.6.15-rc1-new/arch/um/Kconfig.x86_64 2005-11-13 01:55:47.761861224 +0100 @@ -9,7 +9,7 @@ #XXX: this is so in the underlying arch, but it's wrong!!! config RWSEM_GENERIC_SPINLOCK bool - default y + default n config SEMAPHORE_SLEEPERS bool diff -ru linux-2.6.15-rc1/arch/um/Makefile linux-2.6.15-rc1-new/arch/um/Makefile --- linux-2.6.15-rc1/arch/um/Makefile 2005-11-13 02:08:34.318108152 +0100 +++ linux-2.6.15-rc1-new/arch/um/Makefile 2005-11-13 02:01:11.364014056 +0100 @@ -107,7 +107,7 @@ prepare: $(ARCH_DIR)/include/kern_constants.h LINK-$(CONFIG_LD_SCRIPT_STATIC) += -static -LINK-$(CONFIG_LD_SCRIPT_DYN) += -Wl,-rpath,/lib +LINK-$(CONFIG_LD_SCRIPT_DYN) += -Wl,-rpath,/lib64 CPP_MODE-$(CONFIG_MODE_TT) := -DMODE_TT CONFIG_KERNEL_STACK_ORDER ?= 2 Then I ran it with my standard ./linux rootfstype=hostfs rw init=/bin/sh and got the following: Kernel command line: rootfstype=hostfs rw init=/bin/sh root=98:0 PID hash table entries: 256 (order: 8, 8192 bytes) Dentry cache hash table entries: 8192 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) Memory: 30208k available Mount-cache hash table entries: 256 Checking that host ptys support output SIGIO...Yes Checking that host ptys support SIGIO on close...No, enabling workaround Checking for /dev/anon on the host...Not available (open failed with errno 2) Linux NoNET1.0 for Linux 2.6 Using 2.6 host AIO io scheduler noop registered loop: loaded (max 8 devices) Initialized stdio console driver Console initialized on /dev/tty0 Failed to open 'root_fs', errno = 2 VFS: Mounted root (hostfs filesystem). Stub registers - 0 - 9090909090909090 1 - 9090909090909090 2 - 9090909090909090 3 - 9090909090909090 4 - 9090909090909090 5 - 9090909090909090 6 - 9090909090909090 7 - 9090909090909090 8 - 9090909090909090 9 - 9090909090909090 10 - 0 11 - 9090909090909090 12 - 9090909090909090 13 - 9090909090909090 14 - 9090909090909090 15 - ffffffffffffffff 16 - 9090909090909090 17 - 33 18 - 292 19 - 9090909090909090 20 - 2b ... [Remaining registers omitted because Jeff's debug patch iterates with the wrong constants. The corrected version produced only the first 20.] ... Kernel panic - not syncing: get_skas_faultinfo : failed to wait for SIGUSR1/SIGTRAP, pid = 10090, n = 10090, errno = 0, status = 0xb7f Pid: 1, comm: sh Not tainted 2.6.15-rc1 RIP: 0033:[<0000000040000ac0>] RSP: 0000007f7facdfe0 EFLAGS: 00010212 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Call Trace: 6018b6a8: [<60014cba>] panic_exit+0x2a/0x50 6018b6b8: [<60033dff>] notifier_call_chain+0x1f/0x40 6018b6d8: [<6002479f>] panic+0xcf/0x170 6018b6f8: [<6001223c>] set_signals+0x6c/0x130 6018b750: [<60018370>] copy_chunk_to_user+0x0/0x40 6018b7b8: [<60016274>] wait_stub_done+0xd4/0x160 6018b948: [<6008b0fa>] load_elf_binary+0xfa/0x10a0 6018bb08: [<60012157>] enable_mask+0x47/0x70 6018bb28: [<6001223c>] set_signals+0x6c/0x130 6018bbd8: [<6006c508>] do_execve+0x198/0x220 6018bbf0: [<6000da40>] init+0x0/0x180 6018bbf8: [<6001053f>] current_cmd+0x3f/0x70 6018bc30: [<6000da40>] init+0x0/0x180 6018bc38: [<60014669>] do_longjmp+0x9/0x20 6018bc48: [<6000e137>] um_execve+0x47/0x50 6018bc78: [<6000da40>] init+0x0/0x180 6018bd08: [<6001f8d2>] run_kernel_thread+0x52/0xa0 6018bd38: [<6001635a>] get_skas_faultinfo+0x5a/0x70 6018bd48: [<60017e53>] user_signal+0x63/0x90 6018bd68: [<6001691f>] userspace+0x14f/0x1c0 6018bdb0: [<6000da40>] init+0x0/0x180 6018bdc0: [<6000da40>] init+0x0/0x180 6018bdd8: [<600174d7>] new_thread_handler+0x107/0x140 |
From: Blaisorblade <bla...@ya...> - 2005-11-13 17:46:56
|
On Sunday 13 November 2005 02:36, Rob Landley wrote: > I needed to patch two things to get 2.6.15-rc1 to build on an x86-64 > system running PLD linux: > > diff -ru linux-2.6.15-rc1/arch/um/Kconfig.x86_64 > linux-2.6.15-rc1-new/arch/um/Kconfig.x86_64 --- > linux-2.6.15-rc1/arch/um/Kconfig.x86_64 2005-11-13 02:08:34.318108152 +0100 > +++ linux-2.6.15-rc1-new/arch/um/Kconfig.x86_64 2005-11-13 > 01:55:47.761861224 +0100 @@ -9,7 +9,7 @@ > #XXX: this is so in the underlying arch, but it's wrong!!! > config RWSEM_GENERIC_SPINLOCK > bool > - default y > + default n The patch for this (which fixes a couple of other things, too) is attached in this thread and has been sent to -mm (cc'ing uml-devel): [uml-user] 2.6.14.git: user-mode-linux/x86_64 does not build [uml-devel] [PATCH 4/9] uml - fixups for "reuse i386 cpu-specific tuning" > diff -ru linux-2.6.15-rc1/arch/um/Makefile > linux-2.6.15-rc1-new/arch/um/Makefile --- linux-2.6.15-rc1/arch/um/Makefile > 2005-11-13 02:08:34.318108152 +0100 +++ > linux-2.6.15-rc1-new/arch/um/Makefile 2005-11-13 02:01:11.364014056 +0100 > @@ -107,7 +107,7 @@ > prepare: $(ARCH_DIR)/include/kern_constants.h > > LINK-$(CONFIG_LD_SCRIPT_STATIC) += -static > -LINK-$(CONFIG_LD_SCRIPT_DYN) += -Wl,-rpath,/lib > +LINK-$(CONFIG_LD_SCRIPT_DYN) += -Wl,-rpath,/lib64 > > CPP_MODE-$(CONFIG_MODE_TT) := -DMODE_TT > CONFIG_KERNEL_STACK_ORDER ?= 2 Is that _needed_ on your system? I ask because it always worked and it's highly host distro-dependant, I guess. > Then I ran it with my standard ./linux rootfstype=hostfs rw init=/bin/sh > and got the following: > Console initialized on /dev/tty0 > Failed to open 'root_fs', errno = 2 > VFS: Mounted root (hostfs filesystem). > Stub registers - > 0 - 9090909090909090 0x90 is the pad used to fill holes in binaries..., and it's strange it's there. I guess that the dump is taken from the stack and that's how this is printed. > 1 - 9090909090909090 > 2 - 9090909090909090 > 3 - 9090909090909090 > 4 - 9090909090909090 > 5 - 9090909090909090 > 6 - 9090909090909090 > 7 - 9090909090909090 > 8 - 9090909090909090 > 9 - 9090909090909090 > 10 - 0 > 11 - 9090909090909090 > 12 - 9090909090909090 > 13 - 9090909090909090 > 14 - 9090909090909090 > 15 - ffffffffffffffff > 16 - 9090909090909090 > 17 - 33 > 18 - 292 > 19 - 9090909090909090 > 20 - 2b > ... > [Remaining registers omitted because Jeff's debug patch iterates with the > wrong constants. The corrected version produced only the first 20.] > ... > Kernel panic - not syncing: get_skas_faultinfo : failed to wait for > SIGUSR1/SIGTRAP, pid = 10090, n = 10090, errno = 0, status = 0xb7f -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
From: Jeff D. <jd...@ad...> - 2005-11-13 18:40:19
|
On Sat, Nov 12, 2005 at 07:36:41PM -0600, Rob Landley wrote: > Stub registers - > 0 - 9090909090909090 > 1 - 9090909090909090 > 2 - 9090909090909090 > 3 - 9090909090909090 > 4 - 9090909090909090 > 5 - 9090909090909090 > 6 - 9090909090909090 > 7 - 9090909090909090 > 8 - 9090909090909090 > 9 - 9090909090909090 > 10 - 0 > 11 - 9090909090909090 > 12 - 9090909090909090 > 13 - 9090909090909090 > 14 - 9090909090909090 > 15 - ffffffffffffffff > 16 - 9090909090909090 > 17 - 33 > 18 - 292 > 19 - 9090909090909090 > 20 - 2b I remain baffled by this. There is nothing valid there. At the very least RSP and RIP should be reasonable, and they're not. Jeff |
From: Blaisorblade <bla...@ya...> - 2005-11-13 19:12:55
|
On Sunday 13 November 2005 20:32, Jeff Dike wrote: > On Sat, Nov 12, 2005 at 07:36:41PM -0600, Rob Landley wrote: > > Stub registers - > > 0 - 9090909090909090 > > 1 - 9090909090909090 > > 2 - 9090909090909090 > > 3 - 9090909090909090 > > 4 - 9090909090909090 > > 5 - 9090909090909090 > > 6 - 9090909090909090 > > 7 - 9090909090909090 > > 8 - 9090909090909090 > > 9 - 9090909090909090 > > 10 - 0 > > 11 - 9090909090909090 > > 12 - 9090909090909090 > > 13 - 9090909090909090 > > 14 - 9090909090909090 > > 15 - ffffffffffffffff > > 16 - 9090909090909090 > > 17 - 33 > > 18 - 292 > > 19 - 9090909090909090 > > 20 - 2b > > I remain baffled by this. There is nothing valid there. At the very least > RSP and RIP should be reasonable, and they're not. Jeff, given the current state, I think that we need a look at the disassembly - or better: *) build a 2.6.15-rc1 binary with Rob's config. *) test that it works *) send him and see if it works for him *) finally, conclude GCC is misassembling stuff and take measures for this case. Meanwhile, Rob, can you provide the disassembly? We need to look at disassembled arch/um/sys-x86_64/stub_segv.c arch/um/kernel/skas/clone.c, i.e. stub_segv_handler() and stub_clone_handler(). * Also, about the miscompilation bug you described: is it caused by GCC saving the "from" value (UML_CONFIG_STUB_DATA) on the stack and re-loading it? * Ah, Jeff, while giving a casual look: should I remove x86_64 "syscall_stub" label from stub.S, since it should be unused (replaced by batch_syscall_stub), doesn't exist for 386 and the content is bogus? -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Messenger: chiamate gratuite in tutto il mondo http://it.messenger.yahoo.com |
From: Rob L. <ro...@la...> - 2005-11-13 23:26:35
|
On Sunday 13 November 2005 11:54, Blaisorblade wrote: > On Sunday 13 November 2005 02:36, Rob Landley wrote: > > I needed to patch two things to get 2.6.15-rc1 to build on an x86-64 > > system running PLD linux: > > > > diff -ru linux-2.6.15-rc1/arch/um/Kconfig.x86_64 > > linux-2.6.15-rc1-new/arch/um/Kconfig.x86_64 --- > > linux-2.6.15-rc1/arch/um/Kconfig.x86_64 2005-11-13 02:08:34.318108152 > > +0100 +++ linux-2.6.15-rc1-new/arch/um/Kconfig.x86_64 2005-11-13 > > 01:55:47.761861224 +0100 @@ -9,7 +9,7 @@ > > #XXX: this is so in the underlying arch, but it's wrong!!! > > config RWSEM_GENERIC_SPINLOCK > > bool > > - default y > > + default n > > The patch for this (which fixes a couple of other things, too) is attached > in this thread and has been sent to -mm (cc'ing uml-devel): > > [uml-user] 2.6.14.git: user-mode-linux/x86_64 does not build > [uml-devel] [PATCH 4/9] uml - fixups for "reuse i386 cpu-specific tuning" The second one doesn't seem related, and I couldn't find the first one in 2.6.14-mm2 (which is the most recent kernel.org lists)... > > diff -ru linux-2.6.15-rc1/arch/um/Makefile > > linux-2.6.15-rc1-new/arch/um/Makefile --- > > linux-2.6.15-rc1/arch/um/Makefile 2005-11-13 02:08:34.318108152 +0100 +++ > > linux-2.6.15-rc1-new/arch/um/Makefile 2005-11-13 02:01:11.364014056 +0100 > > @@ -107,7 +107,7 @@ > > prepare: $(ARCH_DIR)/include/kern_constants.h > > > > LINK-$(CONFIG_LD_SCRIPT_STATIC) += -static > > -LINK-$(CONFIG_LD_SCRIPT_DYN) += -Wl,-rpath,/lib > > +LINK-$(CONFIG_LD_SCRIPT_DYN) += -Wl,-rpath,/lib64 > > > > CPP_MODE-$(CONFIG_MODE_TT) := -DMODE_TT > > CONFIG_KERNEL_STACK_ORDER ?= 2 > > Is that _needed_ on your system? I ask because it always worked and it's > highly host distro-dependant, I guess. Yes it's needed. Otherwise: CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 /usr/bin/ld: warning: ld-linux-x86-64.so.2, needed by /lib64/libc.so.6, not found (try using -rpath or -rpath-link) /lib64/libc.so.6: undefined reference to `_rtld_global@GLIBC_PRIVATE' /lib64/libc.so.6: undefined reference to `__libc_enable_secure@GLIBC_PRIVATE' /lib64/libc.so.6: undefined reference to `_rtld_global_ro@GLIBC_PRIVATE' /lib64/libc.so.6: undefined reference to `_dl_out_of_memory@GLIBC_PRIVATE' /lib64/libc.so.6: undefined reference to `_r_debug@GLIBC_2.2.5' /lib64/libc.so.6: undefined reference to `__tls_get_addr@GLIBC_2.3' /lib64/libc.so.6: undefined reference to `_dl_argv@GLIBC_PRIVATE' collect2: ld returned 1 exit status KSYM .tmp_kallsyms1.S nm: '.tmp_vmlinux1': No such file No valid symbol. make: *** [.tmp_kallsyms1.S] Bd 1 All that's in /lib on pld is: [rob@rg4 linux-2.6.14]$ ls -l /lib razem 0 lrwxrwxrwx 1 root root 12 2005-09-06 12:21 cpp -> /usr/bin/cpp drwxr-xr-x 2 root root 1 2005-11-05 18:53 firmware drwxr-xr-x 3 root root 16 2005-11-05 18:53 modules As opposed to: [rob@rg4 linux-2.6.14]$ ls -l /lib64 | wc 103 910 7541 > > Then I ran it with my standard ./linux rootfstype=hostfs rw init=/bin/sh > > and got the following: > > > > > > Console initialized on /dev/tty0 > > Failed to open 'root_fs', errno = 2 > > VFS: Mounted root (hostfs filesystem). > > Stub registers - > > 0 - 9090909090909090 > > 0x90 is the pad used to fill holes in binaries..., and it's strange it's > there. I just applied Jeff's patch. I dunno what the output means. Rob |
From: Rob L. <ro...@la...> - 2005-11-13 23:32:22
|
On Sunday 13 November 2005 13:20, Blaisorblade wrote: > On Sunday 13 November 2005 20:32, Jeff Dike wrote: > > On Sat, Nov 12, 2005 at 07:36:41PM -0600, Rob Landley wrote: > > > Stub registers - > > > 0 - 9090909090909090 > > > 1 - 9090909090909090 > > > 2 - 9090909090909090 > > > 3 - 9090909090909090 > > > 4 - 9090909090909090 > > > 5 - 9090909090909090 > > > 6 - 9090909090909090 > > > 7 - 9090909090909090 > > > 8 - 9090909090909090 > > > 9 - 9090909090909090 > > > 10 - 0 > > > 11 - 9090909090909090 > > > 12 - 9090909090909090 > > > 13 - 9090909090909090 > > > 14 - 9090909090909090 > > > 15 - ffffffffffffffff > > > 16 - 9090909090909090 > > > 17 - 33 > > > 18 - 292 > > > 19 - 9090909090909090 > > > 20 - 2b > > > > I remain baffled by this. There is nothing valid there. At the very > > least RSP and RIP should be reasonable, and they're not. > > Jeff, given the current state, I think that we need a look at the > disassembly - or better: > *) build a 2.6.15-rc1 binary with Rob's config. > *) test that it works > *) send him and see if it works for him > *) finally, conclude GCC is misassembling stuff and take measures for this > case. > > Meanwhile, Rob, can you provide the disassembly? We need to look at > disassembled arch/um/sys-x86_64/stub_segv.c arch/um/kernel/skas/clone.c, > i.e. stub_segv_handler() and stub_clone_handler(). 00000000600c5150 <stub_segv_handler>: 600c5150: 48 89 d1 mov %rdx,%rcx 600c5153: 48 ba 00 f0 ff bf 7f mov $0x7fbffff000,%rdx 600c515a: 00 00 00 600c515d: 48 8b 81 d8 00 00 00 mov 0xd8(%rcx),%rax 600c5164: 48 89 42 08 mov %rax,0x8(%rdx) 600c5168: 8b 81 c0 00 00 00 mov 0xc0(%rcx),%eax 600c516e: 89 02 mov %eax,(%rdx) 600c5170: 8b 81 c8 00 00 00 mov 0xc8(%rcx),%eax 600c5176: 89 42 10 mov %eax,0x10(%rdx) 600c5179: 48 c7 c0 27 00 00 00 mov $0x27,%rax 600c5180: 0f 05 syscall 600c5182: 48 89 c7 mov %rax,%rdi 600c5185: 48 c7 c0 3e 00 00 00 mov $0x3e,%rax 600c518c: 48 c7 c6 0a 00 00 00 mov $0xa,%rsi 600c5193: 0f 05 syscall 600c5195: 48 89 cc mov %rcx,%rsp 600c5198: 48 c7 c0 0f 00 00 00 mov $0xf,%rax 600c519f: 0f 05 syscall 600c51a1: c3 retq 00000000600c5000 <stub_clone_handler>: 600c5000: 41 57 push %r15 600c5002: 41 56 push %r14 600c5004: 41 55 push %r13 600c5006: 41 54 push %r12 600c5008: 41 bc 38 00 00 00 mov $0x38,%r12d 600c500e: 55 push %rbp 600c500f: 48 bd 00 f0 ff bf 7f mov $0x7fbffff000,%rbp 600c5016: 00 00 00 600c5019: 53 push %rbx 600c501a: bb 11 84 00 00 mov $0x8411,%ebx 600c501f: 48 83 ec 08 sub $0x8,%rsp 600c5023: e8 70 83 f4 ff callq 6000d398 <getpagesize@plt> 600c5028: 48 89 df mov %rbx,%rdi 600c502b: 89 c6 mov %eax,%esi 600c502d: 41 89 c0 mov %eax,%r8d 600c5030: 48 b8 f8 ef ff bf 7f mov $0x7fbfffeff8,%rax 600c5037: 00 00 00 600c503a: c1 ee 1f shr $0x1f,%esi 600c503d: 42 8d 34 06 lea (%rsi,%r8,1),%esi 600c5041: d1 fe sar %esi 600c5043: 48 63 f6 movslq %esi,%rsi 600c5046: 48 01 c6 add %rax,%rsi 600c5049: 4c 89 e0 mov %r12,%rax 600c504c: 0f 05 syscall 600c504e: 48 85 c0 test %rax,%rax 600c5051: 48 89 c3 mov %rax,%rbx 600c5054: 75 78 jne 600c50ce <stub_clone_handler+0xce> 600c5056: b8 65 00 00 00 mov $0x65,%eax 600c505b: 48 89 df mov %rbx,%rdi 600c505e: 48 89 de mov %rbx,%rsi 600c5061: 48 89 da mov %rbx,%rdx 600c5064: 49 89 da mov %rbx,%r10 600c5067: 0f 05 syscall 600c5069: 48 85 c0 test %rax,%rax 600c506c: 48 89 c3 mov %rax,%rbx 600c506f: 75 5d jne 600c50ce <stub_clone_handler+0xce> 600c5071: b8 26 00 00 00 mov $0x26,%eax 600c5076: bf 01 00 00 00 mov $0x1,%edi 600c507b: 48 be 10 f0 ff bf 7f mov $0x7fbffff010,%rsi 600c5082: 00 00 00 600c5085: 48 89 da mov %rbx,%rdx 600c5088: 0f 05 syscall 600c508a: 48 85 c0 test %rax,%rax 600c508d: 48 89 c3 mov %rax,%rbx 600c5090: 75 3c jne 600c50ce <stub_clone_handler+0xce> 600c5092: a1 08 f0 ff bf 7f 00 mov 0x7fbffff008,%eax 600c5099: 00 00 Rob |
From: Jeff D. <jd...@ad...> - 2005-11-14 14:41:04
|
On Sun, Nov 13, 2005 at 05:32:10PM -0600, Rob Landley wrote: > On Sunday 13 November 2005 13:20, Blaisorblade wrote: > > On Sunday 13 November 2005 20:32, Jeff Dike wrote: > > > On Sat, Nov 12, 2005 at 07:36:41PM -0600, Rob Landley wrote: > > > > Stub registers - > > > > 0 - 9090909090909090 > > > > 1 - 9090909090909090 > > > > 2 - 9090909090909090 > > > > 3 - 9090909090909090 > > > > 4 - 9090909090909090 > > > > 5 - 9090909090909090 > > > > 6 - 9090909090909090 > > > > 7 - 9090909090909090 > > > > 8 - 9090909090909090 > > > > 9 - 9090909090909090 > > > > 10 - 0 > > > > 11 - 9090909090909090 > > > > 12 - 9090909090909090 > > > > 13 - 9090909090909090 > > > > 14 - 9090909090909090 > > > > 15 - ffffffffffffffff > > > > 16 - 9090909090909090 > > > > 17 - 33 > > > > 18 - 292 > > > > 19 - 9090909090909090 > > > > 20 - 2b > > > > > > I remain baffled by this. There is nothing valid there. At the very > > > least RSP and RIP should be reasonable, and they're not. > > I understand this a bit better. We have some signal frame corruption going on. When there's a signal return, somehow RSP is pointing at all these no-ops. Jeff |
From: Blaisorblade <bla...@ya...> - 2005-11-14 20:20:10
|
On Monday 14 November 2005 00:26, Rob Landley wrote: > On Sunday 13 November 2005 11:54, Blaisorblade wrote: > > On Sunday 13 November 2005 02:36, Rob Landley wrote: > > > I needed to patch two things to get 2.6.15-rc1 to build on an x86-64 > > > system running PLD linux: > > > > > > diff -ru linux-2.6.15-rc1/arch/um/Kconfig.x86_64 > > > linux-2.6.15-rc1-new/arch/um/Kconfig.x86_64 --- > > > linux-2.6.15-rc1/arch/um/Kconfig.x86_64 2005-11-13 02:08:34.318108152 > > > +0100 +++ linux-2.6.15-rc1-new/arch/um/Kconfig.x86_64 2005-11-13 > > > 01:55:47.761861224 +0100 @@ -9,7 +9,7 @@ > > > #XXX: this is so in the underlying arch, but it's wrong!!! > > > config RWSEM_GENERIC_SPINLOCK > > > bool > > > - default y > > > + default n > > The patch for this (which fixes a couple of other things, too) is > > attached in this thread and has been sent to -mm (cc'ing uml-devel): > > [uml-user] 2.6.14.git: user-mode-linux/x86_64 does not build > > [uml-devel] [PATCH 4/9] uml - fixups for "reuse i386 cpu-specific tuning" > The second one doesn't seem related, and I couldn't find the first one in > 2.6.14-mm2 (which is the most recent kernel.org lists)... The titles are for ML archives... and the second _is_ related. The problem is that RWSEM_GENERIC_SPINLOCK is the right thing for x86_64, but the i386 Kconfig enables instead RWSEM_XCHGADD_ALGORITHM, which is wrong for x86_64. It compiles, was used at some time, but isn't really tested currently, and Andi Kleen is going to drop the code. So, indeed, your patch is wrong. What the patch does is making sure that Kconfig.i386 is included for _i386_, not for any arch. And it fixes your problem. > > Is that _needed_ on your system? I ask because it always worked and it's > > highly host distro-dependant, I guess. > > Yes it's needed. Otherwise: > CC init/version.o > LD init/built-in.o > LD .tmp_vmlinux1 > /usr/bin/ld: warning: ld-linux-x86-64.so.2, needed by /lib64/libc.so.6, not > found (try using -rpath or -rpath-link) > collect2: ld returned 1 exit status Ok, it's your distro. On mine: # ls -l /lib lrwxrwxrwx 1 root root 5 30 lug 21:17 /lib -> lib64 Anyway, what it's doing could be correct enough to do... except we do the linking with GCC! So probably we could simply remove that -rlink altogether (though the documentation would say otherwise). > > 0x90 is the pad used to fill holes in binaries..., and it's strange it's > > there. > I just applied Jeff's patch. I dunno what the output means. Talking mainly to Jeff there -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
From: Rob L. <ro...@la...> - 2005-11-16 03:09:39
|
On Monday 14 November 2005 13:40, Blaisorblade wrote: > is that RWSEM_GENERIC_SPINLOCK is the right thing for x86_64, but the i386 > Kconfig enables instead RWSEM_XCHGADD_ALGORITHM, which is wrong for x86_64. > It compiles, was used at some time, but isn't really tested currently, and > Andi Kleen is going to drop the code. So, indeed, your patch is wrong. Not saying it's correct, just saying it was the smallest tweak that got me past the build break. (For a little bit there I was editing the #includes by hand.) > What the patch does is making sure that Kconfig.i386 is included for > _i386_, not for any arch. And it fixes your problem. > > > > Is that _needed_ on your system? I ask because it always worked and > > > it's highly host distro-dependant, I guess. > > > > Yes it's needed. Otherwise: > > CC init/version.o > > LD init/built-in.o > > LD .tmp_vmlinux1 > > /usr/bin/ld: warning: ld-linux-x86-64.so.2, needed by /lib64/libc.so.6, > > not found (try using -rpath or -rpath-link) > > collect2: ld returned 1 exit status > > Ok, it's your distro. On mine: > > # ls -l /lib > lrwxrwxrwx 1 root root 5 30 lug 21:17 /lib -> lib64 It's the distro of the nice person who let me borrow their x86-64 machine. Currently, the UML build seems to require that /lib be a symlink to /lib64. This is not the case on PLD, and occording to the Oct 31 post on uml-user it's not the case on CentOS either. I don't know what other distros it's not the case for. > Anyway, what it's doing could be correct enough to do... except we do the > linking with GCC! So probably we could simply remove that -rlink altogether > (though the documentation would say otherwise). I'm all for better solutions. I'm just saying what I needed to do to get it to build with what I had. Rob |
From: Blaisorblade <bla...@ya...> - 2005-11-18 07:34:40
|
On Wednesday 16 November 2005 04:09, Rob Landley wrote: > On Monday 14 November 2005 13:40, Blaisorblade wrote: > > Anyway, what it's doing could be correct enough to do... except we do the > > linking with GCC! So probably we could simply remove that -rlink > > altogether (though the documentation would say otherwise). > > I'm all for better solutions. I'm just saying what I needed to do to get > it to build with what I had. Ok, clearer: could you try removing altogether that -rlink? I'm trying here too right now... will follow up with results. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
From: Rob L. <ro...@la...> - 2005-11-18 07:36:38
|
On Friday 18 November 2005 01:43, Blaisorblade wrote: > On Wednesday 16 November 2005 04:09, Rob Landley wrote: > > On Monday 14 November 2005 13:40, Blaisorblade wrote: > > > Anyway, what it's doing could be correct enough to do... except we do > > > the linking with GCC! So probably we could simply remove that -rlink > > > altogether (though the documentation would say otherwise). > > > > I'm all for better solutions. I'm just saying what I needed to do to get > > it to build with what I had. > > Ok, clearer: could you try removing altogether that -rlink? I'm trying here > too right now... will follow up with results. I believe I tried that already and the error was the same as when it had the wrong directory. Rob |
From: Blaisorblade <bla...@ya...> - 2005-11-18 07:49:20
|
On Friday 18 November 2005 08:36, Rob Landley wrote: > On Friday 18 November 2005 01:43, Blaisorblade wrote: > > On Wednesday 16 November 2005 04:09, Rob Landley wrote: > > > On Monday 14 November 2005 13:40, Blaisorblade wrote: > > Ok, clearer: could you try removing altogether that -rlink? I'm trying > > here too right now... will follow up with results. > I believe I tried that already and the error was the same as when it had > the wrong directory. Ok, right - can you try adding both rlink now (first lib64 and then lib)? I gathered some more insight and it should work. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
From: Rob L. <ro...@la...> - 2005-11-18 08:58:12
|
On Friday 18 November 2005 01:58, Blaisorblade wrote: > On Friday 18 November 2005 08:36, Rob Landley wrote: > > On Friday 18 November 2005 01:43, Blaisorblade wrote: > > > On Wednesday 16 November 2005 04:09, Rob Landley wrote: > > > > On Monday 14 November 2005 13:40, Blaisorblade wrote: > > > > > > Ok, clearer: could you try removing altogether that -rlink? I'm trying > > > here too right now... will follow up with results. > > > > I believe I tried that already and the error was the same as when it had > > the wrong directory. > > Ok, right - can you try adding both rlink now (first lib64 and then lib)? I > gathered some more insight and it should work. Actually, since the rpath line appends arguments to whatever's already there and Makefile-$ARCH gets included before that, I suspect the correct thing to do is append LINK-$(CONFIG_LD_SCRIPT_DYN) += -Wl,-rpath,/lib64 to the end of "arch/um/Makefile-x86_64". Order should work out ok, and the path is only modified for x86-64... The ld man page says: -rpath dir Add a directory to the runtime library search path. This is used when linking an ELF executable with shared objects. All -rpath arguments are concatenated and passed to the runtime linker, which uses them to locate shared objects at runtime. The -rpath option is also used when locating shared objects which are needed by shared objects explicitly included in the link; see the description of the -rpath-link option. So that concatenates multiple arguments... And it worked beautifully. Here's your patch: --- linux-2.6.14/arch/um/Makefile-x86_64 2005-10-28 02:02:08.000000000 +0200 +++ linux-2.6.15-rc1/arch/um/Makefile-x86_64 2005-11-18 09:55:39.984601688 +0100 @@ -12,3 +12,5 @@ ELF_ARCH := i386:x86-64 ELF_FORMAT := elf64-x86-64 + +LINK-$(CONFIG_LD_SCRIPT_DYN) += -Wl,-rpath,/lib64 Rob |
From: Rob L. <ro...@la...> - 2005-11-19 00:12:08
|
Signed-off-by: Rob Landley <ro...@la...> The current UML build assumes that on x86-64 systems, /lib is a symlink to /lib64, but in some distributions (like PLD and CentOS) they are separate directories, so the 64 bit library loader isn't found. This patch inserts /lib64 at the start of the rpath on x86-64 UML builds. --- --- linux-2.6.14/arch/um/Makefile-x86_64 2005-10-28 02:02:08.000000000 +0200 +++ linux-2.6.15-rc1/arch/um/Makefile-x86_64 2005-11-18 09:55:39.984601688 +0100 @@ -12,3 +12,5 @@ ELF_ARCH := i386:x86-64 ELF_FORMAT := elf64-x86-64 + +LINK-$(CONFIG_LD_SCRIPT_DYN) += -Wl,-rpath,/lib64 Rob |