[uml-devel] [PATCH] Ok, I build x86-64 -skas0, and it still segfaults.

[uml-devel] [PATCH] Ok, I build x86-64 -skas0, and it still segfaults.

[Rob Landley]

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




-------------------------------------------------------
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] Ok, I build x86-64 -skas0, and it still segfaults.

[Blaisorblade]

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



-------------------------------------------------------
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] Ok, I build x86-64 -skas0, and it still segfaults.

[Rob Landley]

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


-------------------------------------------------------
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] Ok, I build x86-64 -skas0, and it still segfaults.

[Blaisorblade]

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



-------------------------------------------------------
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] Ok, I build x86-64 -skas0, and it still segfaults.

[Rob Landley]

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


-------------------------------------------------------
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] Ok, I build x86-64 -skas0, and it still segfaults.

[Blaisorblade]

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



-------------------------------------------------------
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] Ok, I build x86-64 -skas0, and it still segfaults.

[Rob Landley]

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


-------------------------------------------------------
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] Ok, I build x86-64 -skas0, and it still segfaults.

[Blaisorblade]

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



-------------------------------------------------------
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] Ok, I build x86-64 -skas0, and it still segfaults.

[Rob Landley]

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


-------------------------------------------------------
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] [PATCH] UML x86-64 build fix.

[Rob Landley]

Signed-off-by: Rob Landley <rob@landley.net>

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] Ok, I build x86-64 -skas0, and it still segfaults.

[Jeff Dike]

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


-------------------------------------------------------
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] Ok, I build x86-64 -skas0, and it still segfaults.

[Blaisorblade]

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



-------------------------------------------------------
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] Ok, I build x86-64 -skas0, and it still segfaults.

[Rob Landley]

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


-------------------------------------------------------
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] Ok, I build x86-64 -skas0, and it still segfaults.

[Jeff Dike]

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


-------------------------------------------------------
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] Ok, I build x86-64 -skas0, and it still segfaults.

[Jeff Dike]

[-- Attachment #1: Type: text/plain, Size: 302 bytes --]

On Sun, Nov 13, 2005 at 05:32:10PM -0600, Rob Landley wrote:
> moan moan

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


[-- Attachment #2: x86-64-clobbers-rcx --]
[-- Type: text/plain, Size: 5717 bytes --]

Index: linux-2.6.14/arch/um/include/sysdep-i386/stub.h
===================================================================
--- linux-2.6.14.orig/arch/um/include/sysdep-i386/stub.h	2005-11-14 15:48:21.000000000 -0500
+++ linux-2.6.14/arch/um/include/sysdep-i386/stub.h	2005-11-14 15:48:30.000000000 -0500
@@ -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
===================================================================
--- linux-2.6.14.orig/arch/um/include/sysdep-x86_64/stub.h	2005-11-14 15:45:09.000000000 -0500
+++ linux-2.6.14/arch/um/include/sysdep-x86_64/stub.h	2005-11-14 15:45:21.000000000 -0500
@@ -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
===================================================================
--- linux-2.6.14.orig/arch/um/sys-i386/Makefile	2005-11-10 11:42:11.000000000 -0500
+++ linux-2.6.14/arch/um/sys-i386/Makefile	2005-11-14 15:49:12.000000000 -0500
@@ -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
===================================================================
--- linux-2.6.14.orig/arch/um/sys-i386/stub_segv.c	2005-11-10 11:41:46.000000000 -0500
+++ linux-2.6.14/arch/um/sys-i386/stub_segv.c	2005-11-14 15:56:22.000000000 -0500
@@ -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
===================================================================
--- linux-2.6.14.orig/arch/um/sys-x86_64/Makefile	2005-11-04 14:43:30.000000000 -0500
+++ linux-2.6.14/arch/um/sys-x86_64/Makefile	2005-11-14 15:45:21.000000000 -0500
@@ -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
===================================================================
--- linux-2.6.14.orig/arch/um/sys-x86_64/stub_segv.c	2005-11-14 15:45:09.000000000 -0500
+++ linux-2.6.14/arch/um/sys-x86_64/stub_segv.c	2005-11-14 15:45:21.000000000 -0500
@@ -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);
 }

[-- Attachment #3: fix-x86-stubs --]
[-- Type: text/plain, Size: 6521 bytes --]

# From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
# 
# 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 <blaisorblade@yahoo.it>
# ---
# 
#  arch/um/include/sysdep-i386/stub.h   |   64 +++++++++++++++++++++++-----------
#  arch/um/include/sysdep-x86_64/stub.h |   61 ++++++++++++++++++++++++++------
#  2 files changed, 92 insertions(+), 33 deletions(-)
# 
diff --git a/arch/um/include/sysdep-i386/stub.h b/arch/um/include/sysdep-i386/stub.h
--- a/arch/um/include/sysdep-i386/stub.h
+++ b/arch/um/include/sysdep-i386/stub.h
@@ -16,45 +16,69 @@ extern void stub_clone_handler(void);
 #define STUB_MMAP_NR __NR_mmap2
 #define MMAP_OFFSET(o) ((o) >> PAGE_SHIFT)
 
+static inline long stub_syscall1(long syscall, long arg1)
+{
+	long ret;
+
+	__asm__ volatile ("int $0x80" : "=a" (ret) : "0" (syscall), "b" (arg1));
+
+	return ret;
+}
+
 static inline long stub_syscall2(long syscall, long arg1, long arg2)
 {
 	long ret;
 
-	__asm__("movl %0, %%ecx; " : : "g" (arg2) : "%ecx");
-	__asm__("movl %0, %%ebx; " : : "g" (arg1) : "%ebx");
-	__asm__("movl %0, %%eax; " : : "g" (syscall) : "%eax");
-	__asm__("int $0x80;" : : : "%eax");
-	__asm__ __volatile__("movl %%eax, %0; " : "=g" (ret) :);
-	return(ret);
+	__asm__ volatile ("int $0x80" : "=a" (ret) : "0" (syscall), "b" (arg1),
+			"c" (arg2));
+
+	return ret;
 }
 
 static inline long stub_syscall3(long syscall, long arg1, long arg2, long arg3)
 {
-	__asm__("movl %0, %%edx; " : : "g" (arg3) : "%edx");
-	return(stub_syscall2(syscall, arg1, arg2));
+	long ret;
+
+	__asm__ volatile ("int $0x80" : "=a" (ret) : "0" (syscall), "b" (arg1),
+			"c" (arg2), "d" (arg3));
+
+	return ret;
 }
 
 static inline long stub_syscall4(long syscall, long arg1, long arg2, long arg3,
 				 long arg4)
 {
-	__asm__("movl %0, %%esi; " : : "g" (arg4) : "%esi");
-	return(stub_syscall3(syscall, arg1, arg2, arg3));
+	long ret;
+
+	__asm__ volatile ("int $0x80" : "=a" (ret) : "0" (syscall), "b" (arg1),
+			"c" (arg2), "d" (arg3), "S" (arg4));
+
+	return ret;
+}
+
+static inline long stub_syscall5(long syscall, long arg1, long arg2, long arg3,
+				 long arg4, long arg5)
+{
+	long ret;
+
+	__asm__ volatile ("int $0x80" : "=a" (ret) : "0" (syscall), "b" (arg1),
+			"c" (arg2), "d" (arg3), "S" (arg4), "D" (arg5));
+
+	return ret;
 }
 
 static inline long stub_syscall6(long syscall, long arg1, long arg2, long arg3,
 				 long arg4, long arg5, long arg6)
 {
 	long ret;
-	__asm__("movl %0, %%eax; " : : "g" (syscall) : "%eax");
-	__asm__("movl %0, %%ebx; " : : "g" (arg1) : "%ebx");
-	__asm__("movl %0, %%ecx; " : : "g" (arg2) : "%ecx");
-	__asm__("movl %0, %%edx; " : : "g" (arg3) : "%edx");
-	__asm__("movl %0, %%esi; " : : "g" (arg4) : "%esi");
-	__asm__("movl %0, %%edi; " : : "g" (arg5) : "%edi");
-	__asm__ __volatile__("pushl %%ebp ; movl %1, %%ebp; "
-		"int $0x80; popl %%ebp ; "
-		"movl %%eax, %0; " : "=g" (ret) : "g" (arg6) : "%eax");
-	return(ret);
+
+	__asm__ volatile ("push %%ebp ; movl %%eax,%%ebp ; movl %1,%%eax ; "
+			"int $0x80 ; pop %%ebp"
+			: "=a" (ret)
+			: "g" (syscall), "b" (arg1), "c" (arg2), "d" (arg3),
+			  "S" (arg4), "D" (arg5), "0" (arg6));
+
+	return ret;
 }
 
 static inline void trap_myself(void)
diff --git a/arch/um/include/sysdep-x86_64/stub.h b/arch/um/include/sysdep-x86_64/stub.h
--- a/arch/um/include/sysdep-x86_64/stub.h
+++ b/arch/um/include/sysdep-x86_64/stub.h
@@ -17,37 +17,72 @@ extern void stub_clone_handler(void);
 #define STUB_MMAP_NR __NR_mmap
 #define MMAP_OFFSET(o) (o)
 
+#define __syscall_clobber "r11","rcx","memory"
+#define __syscall "syscall"
+
 static inline long stub_syscall2(long syscall, long arg1, long arg2)
 {
 	long ret;
 
-	__asm__("movq %0, %%rsi; " : : "g" (arg2) : "%rsi");
-	__asm__("movq %0, %%rdi; " : : "g" (arg1) : "%rdi");
-	__asm__("movq %0, %%rax; " : : "g" (syscall) : "%rax");
-	__asm__("syscall;" : : : "%rax", "%r11", "%rcx");
-	__asm__ __volatile__("movq %%rax, %0; " : "=g" (ret) :);
-	return(ret);
+	__asm__ volatile (__syscall
+		: "=a" (ret)
+		: "0" (syscall), "D" (arg1), "S" (arg2) : __syscall_clobber );
+
+	return ret;
 }
 
 static inline long stub_syscall3(long syscall, long arg1, long arg2, long arg3)
 {
-	__asm__("movq %0, %%rdx; " : : "g" (arg3) : "%rdx");
-	return(stub_syscall2(syscall, arg1, arg2));
+	long ret;
+
+	__asm__ volatile (__syscall
+		: "=a" (ret)
+		: "0" (syscall), "D" (arg1), "S" (arg2), "d" (arg3)
+		: __syscall_clobber );
+
+	return ret;
 }
 
 static inline long stub_syscall4(long syscall, long arg1, long arg2, long arg3,
 				 long arg4)
 {
-	__asm__("movq %0, %%r10; " : : "g" (arg4) : "%r10");
-	return(stub_syscall3(syscall, arg1, arg2, arg3));
+	long ret;
+
+	__asm__ volatile ("movq %5,%%r10 ; " __syscall
+		: "=a" (ret)
+		: "0" (syscall), "D" (arg1), "S" (arg2), "d" (arg3),
+		  "g" (arg4)
+		: __syscall_clobber, "r10" );
+
+	return ret;
+}
+
+static inline long stub_syscall5(long syscall, long arg1, long arg2, long arg3,
+				 long arg4, long arg5)
+{
+	long ret;
+
+	__asm__ volatile ("movq %5,%%r10 ; movq %6,%%r8 ; " __syscall
+		: "=a" (ret)
+		: "0" (syscall), "D" (arg1), "S" (arg2), "d" (arg3),
+		  "g" (arg4), "g" (arg5)
+		: __syscall_clobber, "r10", "r8" );
+
+	return ret;
 }
 
 static inline long stub_syscall6(long syscall, long arg1, long arg2, long arg3,
 				 long arg4, long arg5, long arg6)
 {
-	__asm__("movq %0, %%r9; " : : "g" (arg6) : "%r9");
-	__asm__("movq %0, %%r8; " : : "g" (arg5) : "%r8");
-	return(stub_syscall4(syscall, arg1, arg2, arg3, arg4));
+	long ret;
+
+	__asm__ volatile ("movq %5,%%r10 ; movq %6,%%r8 ; "
+		"movq %7, %%r9; " __syscall : "=a" (ret)
+		: "0" (syscall), "D" (arg1), "S" (arg2), "d" (arg3),
+		  "g" (arg4), "g" (arg5), "g" (arg6)
+		: __syscall_clobber, "r10", "r8", "r9" );
+
+	return ret;
 }
 
 static inline void trap_myself(void)

Re: [uml-devel] [PATCH] Ok, I build x86-64 -skas0, and it still segfaults.

[Rob Landley]

On Monday 14 November 2005 15:55, Jeff Dike wrote:
> On Sun, Nov 13, 2005 at 05:32:10PM -0600, Rob Landley wrote:
> > moan moan

And proud of it!

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

Sure.  (Rummages...)

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

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] Ok, I build x86-64 -skas0, and it still segfaults.

[Rob Landley]

On Monday 14 November 2005 17:24, Rob Landley wrote:
> On Monday 14 November 2005 15:55, Jeff Dike wrote:
> > On Sun, Nov 13, 2005 at 05:32:10PM -0600, Rob Landley wrote:
> > > moan moan
>
> And proud of it!
>
> > Can you try the x86-64-clobbers-rcx patch below?
>
> Sure.  (Rummages...)
>
> > If you don't have it already, apply the fix-x86-stubs patch first.
>
> 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

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] Ok, I build x86-64 -skas0, and it still segfaults.

[Jeff Dike]

On Mon, Nov 14, 2005 at 05:45:44PM -0600, Rob Landley wrote:
> 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:

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] Ok, I build x86-64 -skas0, and it still segfaults.

[Rob Landley]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

On Monday 14 November 2005 19:38, Jeff Dike wrote:
> On Mon, Nov 14, 2005 at 05:45:44PM -0600, Rob Landley wrote:
> > 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:
>
> 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

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?

[-- Attachment #2: headers.patch --]
[-- Type: text/x-diff, Size: 466 bytes --]

--- linux-2.6.15-rc1/arch/um/sys-x86_64/stub_segv.c	2005-11-14 23:20:54.855517272 +0100
+++ linux-2.6.14/arch/um/sys-x86_64/stub_segv.c	2005-11-15 03:11:28.580804656 +0100
@@ -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"

Re: [uml-devel] [PATCH] Ok, I build x86-64 -skas0, and it still segfaults.

[Paolo Giarrusso]

--- Jeff Dike <jdike@addtoit.com> ha scritto: 

> On Sun, Nov 13, 2005 at 05:32:10PM -0600, Rob Landley wrote:
> > moan moan
> 
> 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.

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 :-( ):

> Index: linux-2.6.14/arch/um/sys-i386/stub_segv.c
> ===================================================================
> --- linux-2.6.14.orig/arch/um/sys-i386/stub_segv.c	2005-11-10
> 11:41:46.000000000 -0500
> +++ linux-2.6.14/arch/um/sys-i386/stub_segv.c	2005-11-14
> 15:56:22.000000000 -0500
> @@ -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)); */

Where does this commented getpid + kill comes from? It seems to come
from rubbish in some patch.

Actually, you leave it there for x86-64 - and while I've not looked
at the meaning of what it's doing (sorry but it's late here), it's
anyway bogus (and in fact it doesn't apply anywhere).

And, more important:

>  	/* 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);
>  }

The idea would be nice, but I am reluctant in trusting GCC to leave
%esp unaltered; also, without volatile, GCC feels probably allowed to
move this instruction anywhere in the code.

Actually, I start feeling this could be moved to assembly.

Here and for x86-64, I would rather hardcode this final syscall as
done currently, rather than using the common macros.

For the other syscalls, it's fully ok to reuse the common macros.
> Index: linux-2.6.14/arch/um/sys-x86_64/stub_segv.c
> ===================================================================
> --- linux-2.6.14.orig/arch/um/sys-x86_64/stub_segv.c	2005-11-14
> 15:45:09.000000000 -0500
> +++ linux-2.6.14/arch/um/sys-x86_64/stub_segv.c	2005-11-14
> 15:45:21.000000000 -0500
> @@ -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);
>  }




		
___________________________________ 
Yahoo! Messenger: chiamate gratuite in tutto il mondo 
http://it.messenger.yahoo.com


-------------------------------------------------------
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] Ok, I build x86-64 -skas0, and it still segfaults.

[Jeff Dike]

On Tue, Nov 15, 2005 at 11:09:03PM +0100, Paolo Giarrusso wrote:
> 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. 

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?

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

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.

> > -/*	__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)); */
> 
> Where does this commented getpid + kill comes from? It seems to come
> from rubbish in some patch.

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

> The idea would be nice, but I am reluctant in trusting GCC to leave
> %esp unaltered; also, without volatile, GCC feels probably allowed to
> move this instruction anywhere in the code.

OK, I changed it back.

> Actually, I start feeling this could be moved to assembly.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel