Ok, I build x86-64 -skas0, and it still segfaults.

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
@@ -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
@@ -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

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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"

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.

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



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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)...

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

I just applied Jeff's patch. I dunno what the output means.

Rob

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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.

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).

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



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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.)

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.

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

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

I believe I tried that already and the error was the same as when it had the wrong directory.

Rob

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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:

@@ -12,3 +12,5 @@
 
 ELF_ARCH := i386:x86-64
 ELF_FORMAT := elf64-x86-64
+
+LINK-$(CONFIG_LD_SCRIPT_DYN) += -Wl,-rpath,/lib64

Rob

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Can you try the x86-64-clobbers-rcx patch below?

If you don't have it already, apply the fix-x86-stubs patch first.

Paolo, could you eyeball this one for me? This applies the stub_syscall* goodness to stub_segv.c.

Jeff

Index: linux-2.6.14/arch/um/include/sysdep-i386/stub.h
===================================================================
@@ -16,6 +16,15 @@ extern void stub_clone_handler(void);
 #define STUB_MMAP_NR __NR_mmap2
 #define MMAP_OFFSET(o) ((o) >> PAGE_SHIFT)
 
+static inline long stub_syscall0(long syscall)
+{
+	long ret;
+
+	__asm__ volatile ("int $0x80" : "=a" (ret) : "0" (syscall));
+
+	return ret;
+}
+
 static inline long stub_syscall1(long syscall, long arg1)
 {
 	long ret;

Index: linux-2.6.14/arch/um/include/sysdep-x86_64/stub.h
===================================================================
@@ -6,7 +6,6 @@
 #ifndef __SYSDEP_STUB_H
 #define __SYSDEP_STUB_H
 
-#include <asm/ptrace.h>
 #include <asm/unistd.h>
 #include <sysdep/ptrace_user.h>
 

@@ -20,6 +19,17 @@ extern void stub_clone_handler(void);
 #define __syscall_clobber "r11","rcx","memory"
 #define __syscall "syscall"
 
+static inline long stub_syscall0(long syscall)
+{
+	long ret;
+
+	__asm__ volatile (__syscall
+		: "=a" (ret)
+		: "0" (syscall) : __syscall_clobber );
+
+	return ret;
+}
+
 static inline long stub_syscall2(long syscall, long arg1, long arg2)
 {
 	long ret;

Index: linux-2.6.14/arch/um/sys-i386/Makefile
===================================================================
@@ -5,7 +5,7 @@ obj-y = bitops.o bugs.o checksum.o delay
 obj-$(CONFIG_HIGHMEM) += highmem.o
 obj-$(CONFIG_MODULES) += module.o
 
-USER_OBJS := bugs.o ptrace_user.o sigcontext.o fault.o
+USER_OBJS := bugs.o ptrace_user.o sigcontext.o fault.o stub_segv.o
 
 SYMLINKS = bitops.c semaphore.c highmem.c module.c
 

Index: linux-2.6.14/arch/um/sys-i386/stub_segv.c
===================================================================
@@ -3,9 +3,11 @@
  * Licensed under the GPL
  */
 
+#include <sys/select.h> /* The only way I can see to get sigset_t */
 #include <asm/signal.h>
 #include <asm/unistd.h>
 #include "uml-config.h"
+#include "sysdep/stub.h"
 #include "sysdep/sigcontext.h"
 #include "sysdep/faultinfo.h"
 

@@ -17,13 +19,10 @@ stub_segv_handler(int sig)
 	GET_FAULTINFO_FROM_SC(*((struct faultinfo *) UML_CONFIG_STUB_DATA),
 			      sc);
 
-/*	__asm__("movl %0, %%eax ; int $0x80": : "g" (__NR_getpid));
-	__asm__("movl %%eax, %%ebx ; movl %0, %%eax ; movl %1, %%ecx ;"
-		"int $0x80": : "g" (__NR_kill), "g" (SIGUSR1)); */
 	/* Load pointer to sigcontext into esp, since we need to leave
 	 * the stack in its original form when we do the sigreturn here, by
 	 * hand.
 	 */
-	__asm__("mov %0,%%esp ; movl %1, %%eax ; "
-		"int $0x80" : : "a" (sc), "g" (__NR_sigreturn));
+	__asm__("mov %0,%%esp" : : "a" (sc));
+	stub_syscall0(__NR_sigreturn);
 }

Index: linux-2.6.14/arch/um/sys-x86_64/Makefile
===================================================================
@@ -12,7 +12,7 @@ lib-y = bitops.o bugs.o csum-partial.o d
 obj-y := ksyms.o
 obj-$(CONFIG_MODULES) += module.o um_module.o
 
-USER_OBJS := ptrace_user.o sigcontext.o
+USER_OBJS := ptrace_user.o sigcontext.o stub_segv.o
 
 SYMLINKS = bitops.c csum-copy.S csum-partial.c csum-wrappers.c gate_vma.c \
 	ldt.c memcpy.S thunk.S module.c

Index: linux-2.6.14/arch/um/sys-x86_64/stub_segv.c
===================================================================
@@ -3,13 +3,16 @@
  * Licensed under the GPL
  */
 
-#include <asm/signal.h>
 #include <linux/compiler.h>
+#include <asm/signal.h>
 #include <asm/unistd.h>
+#include <asm/sigcontext.h>
+#include <asm/siginfo.h>
 #include <asm/ucontext.h>
 #include "uml-config.h"
 #include "sysdep/sigcontext.h"
 #include "sysdep/faultinfo.h"
+#include "sysdep/stub.h"
 #include <stddef.h>
 
 /* Copied from sys-x86_64/signal.c - Can't find an equivalent definition

@@ -31,15 +34,15 @@ void __attribute__ ((__section__ (".__sy
 stub_segv_handler(int sig)
 {
 	struct ucontext *uc;
+        int pid;
 
 	__asm__("movq %%rdx, %0" : "=g" (uc) :);
 	GET_FAULTINFO_FROM_SC(*((struct faultinfo *) UML_CONFIG_STUB_DATA),
 			      &uc->uc_mcontext);
 
-	__asm__("movq %0, %%rax ; syscall": : "g" (__NR_getpid));	
-	__asm__("movq %%rax, %%rdi ; movq %0, %%rax ; movq %1, %%rsi ;"
-		"syscall": : "g" (__NR_kill), "g" (SIGUSR1) : 
-		"%rdi", "%rax", "%rsi");
+	pid = stub_syscall0(__NR_getpid);
+	stub_syscall2(__NR_kill, pid, SIGUSR1);
+
 	/* sys_sigreturn expects that the stack pointer will be 8 bytes into
 	 * the signal frame.  So, we use the ucontext pointer, which we know
 	 * already, to get the signal frame pointer, and add 8 to that.

@@ -47,5 +50,5 @@ stub_segv_handler(int sig)
 	__asm__("movq %0, %%rsp": : 
 		"g" ((unsigned long) container_of(uc, struct rt_sigframe, 
 						  uc) + 8));
-	__asm__("movq %0, %%rax ; syscall" : : "g" (__NR_rt_sigreturn));
+	stub_syscall0(__NR_rt_sigreturn);
 }

# From: Paolo 'Blaisorblade' Giarrusso <[email protected]>
#
# Jeff Dike noted that the assembly code for syscall stubs is misassembled with # GCC 3.2.3: the values copied in registers weren't preserved between one asm()

# and the following one.
# 
# So I fixed the thing by rewriting the __asm__ constraints more
# like unistd.h ones.
# 
# Note: in syscall6 case I had to add one more instruction (i.e. moving arg6 in
# eax and shuffling things around) - it's needed for the function to be valid 
# in general (we can't load the value from the stack, relative to ebp, because 
# we change it), but could be avoided since we actually use a constant as 
# param 6.
# 
# The only fix would be to turn stub_syscall6 to a macro and use a "i" 
# constraint for arg6 (i.e., specify it's a constant value).
# 
# Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
# ---
# 
#  arch/um/include/sysdep-i386/stub.h   |   64 +++++++++++++++++++++++-----------
#  arch/um/include/sysdep-x86_64/stub.h |   61 ++++++++++++++++++++++++++------
#  2 files changed, 92 insertions(+), 33 deletions(-)
# 

And proud of it!

Sure. (Rummages...)

It said it was reversed, so I'm going to assume for the moment that 2.6.15-rc1 already has it, try the second...

patching file arch/um/sys-i386/stub_segv.c
Hunk #2 FAILED at 19.
1 out of 2 hunks FAILED -- saving rejects to file
arch/um/sys-i386/stub_segv.c.rej

Ok, fix that up by hand... And the build breaks in stub_segv.c.

What version are these patches against? Let's try a straight 2.6.14...

fix-x86-stubs applied cleanly.
x86-64-clobbers-rcx... Still fails hunk #2.

Back off to a clean 2.6.14 again and try clobbers-rcx first...

Still fails hunk #2.

Rob

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

The breakage, by the way, (which occurs when you fix the failing hunk #2 up by hand) stems from the inability to find asm/signal.h:

CC arch/um/sys-x86_64/stub_segv.o
arch/um/sys-x86_64/stub_segv.c:7:24: asm/signal.h: Nie ma takiego pliku ani katalogu
In file included from /usr/include/linux/siginfo.h:1,

                 from /usr/include/asm-x86_64/siginfo.h:8,
                 from /usr/include/asm/siginfo.h:12,
                 from arch/um/sys-x86_64/stub_segv.c:10:
/usr/include/linux/signal.h:2:2: warning: #warning "You should include 
<signal.h>. This time I will do it for you."
In file included from /usr/include/signal.h:333,
                 from /usr/include/linux/signal.h:4,
                 from /usr/include/linux/siginfo.h:1,
                 from /usr/include/asm-x86_64/siginfo.h:8,
                 from /usr/include/asm/siginfo.h:12,
                 from arch/um/sys-x86_64/stub_segv.c:10:

And so on... (The x86-64 server I'm borrowing is in poland, hence the weird file not found messages).

This is because the actual build line is this:

gcc -Wp,-MD,arch/um/sys-x86_64/.stub_segv.o.d -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -ffreestanding -O2 -fomit-frame-pointer -D__arch_um__ -DSUBARCH=\"x86_64\" -Dvmap=kernel_vmap -Din6addr_loopback=kernel_in6addr_loopback -Iarch/um/include -I/srv/staff/rob/firmware-build/sources/packages/linux-2.6.14/arch/um/kernel/skas/include -fno-builtin -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -c -o arch/um/sys-x86_64/stub_segv.o arch/um/sys-x86_64/stub_segv.c

And neither the arch/um/include nor the arch/um/kernel/skas/include directories contain an "asm" symlink.

[rob@rg4 linux-2.6.14]$ find arch/um -name "asm"
[rob@rg4 linux-2.6.14]$

I have no idea if any of this helps...

Rob

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

What distro is this? asm/signal is in glibc-kernheaders here:

% rpm -q -f /usr/include/asm/signal.h
glibc-kernheaders-2.4-9.1.94

Jeff

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Well, according to /proc/version, it's PLD:

Linux version 2.6.11.10-6 (builder@serwus) (gcc version 3.3.5 (PLD Linux)) #1 Fri May 27 20:55:12 UTC 2005

rpm has a package "basesystem" that's version 1.99.

Here's their web page: http://www.pld.org.pl/

I think this is the distro Maszur originally did his linux-libc-headers package for, so I'm guessing that's what they're using. (Not the glibc stuff.) I use uClibc a lot elsewhere, and that generally uses Mazur's headers rather than the glibc ones too.

It has:

[rob@rg4 include]$ find /usr/include -name signal.h /usr/include/linux/signal.h /usr/include/signal.h /usr/include/sys/signal.h

Hmm, I'm somewhat familiar with Mazur's headers and may be able to fix this up...

Ok, the attached patch builds for me. (I didn't say it was _right_, I said it builds. :)

And let's see how it runs...

Nope, same failure. Want the new panic and register dump?

@@ -4,11 +4,9 @@
  */
 
 #include <linux/compiler.h>
-#include <asm/signal.h>
+#include <signal.h>
 #include <asm/unistd.h>
 #include <asm/sigcontext.h>
-#include <asm/siginfo.h>
-#include <asm/ucontext.h>
 #include "uml-config.h"
 #include "sysdep/sigcontext.h"
 #include "sysdep/faultinfo.h"

--- Jeff Dike <[email protected]> ha scritto:

Thanks for requesting.

I've come to a (possible) conclusion - probably we could try to adapt and reuse the batching syscall stub to do everything. With the original single-syscall stub it didn't make sense, with this one it could do. Yep, there's something to do since stub_segv does some interesting stuff, but I guess it's solvable - I'll look to the code ASAP (I'm finding it difficult these days to leave some time for proper hacking, and I'm very sorry for that).

Or anyway, it's possibly becoming harder to write all this in C with assembly inserts rather than directly in assembly. It also does not work well on some strange compilers (aka Hardened GCC, as reported by Antoine Martin).

However, back on _this_ patch, I have a couple of complaints/suggestions (and sorry for the mess-up, I'm currently answering from web-mail :-( ):

What would that look like? An array of numbers representing register values to be given to the batch syscall stub? Or the syscall_stub* macros would fill in an array?

I'm wondering about this as well. I'm unsure whether we are mopping up the last few problems, or whether we will just be seeing misassembly after misassembly.

At least this patch is a clear bug fix.

This patch was at the end of my series - the current version doesn't have this.

OK, I changed it back.

Maybe. I prefer C as long as that is viable, though.

Jeff

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel