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

[Jeff Dike <jdike@addtoit.com>]

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