Fwd: Re: [patch 1/4] UML Support - Ptrace: adds the host SYSEMU support, for UML and general usage

[Blaisorblade]

----------  Forwarded Message  ----------

Subject: Re: [patch 1/4] UML Support - Ptrace: adds the host SYSEMU support, 
for UML and general usage
Date: Wednesday 27 July 2005 20:40
From: Blaisorblade <blaisorblade@xxxxxxxx>
To: "Charles P. Wright" <cwright@xxxxxxxxxxxxx>
Cc: Bodo Stroesser <bstroesser@xxxxxxxxxxxxxxxxxxx>, Jeff Dike 
<jdike@xxxxxxxxxxx>

On Wednesday 27 July 2005 19:19, Charles P. Wright wrote:
> Paolo,
>
> I'm also using ptrace to emulate system calls for a file system project
> that I'm working on, so needless to say this patch is quite interesting
> for me.
>
> However, I'm not quite sure how the user-level interface is
> supposed to work from the comments.
>
> Normally the flow looks something like the following:
>
> pid = wait();  	/* To trap the syscall entry. */
> if (emulation) {
> 	/* Set the eax value to something invalid. */
> }
> ptrace(PTRACE_SYSCALL, pid); /* Let the call execute. */
> pid = wait();  	/* To trap the syscall exit. */
> if (emualation) {
> 	/* Force a return value. */
> }
> ptrace(PTRACE_SYSCALL);	/* To go back to user code. */
>
> Ideally,
>
> I would like to do the following as I only emulate some of the
> system calls,

Hmm, yes, this is a problem in the current SYSEMU interface, if to be used in
this way.

> and from the code, it seems like I should be able to:
>
> pid = wait();  	/* To trap the syscall entry. */
> if (emulation) {
> 	/* Force a return value. */
> 	ptrace(PTRACE_SYSEMU, pid); /* Go back to user code */
> } else {
> 	ptrace(PTRACE_SYSCALL); /* Let the call execute. */
> 	pid = wait();  	/* To trap the syscall exit. */
> 	ptrace(PTRACE_SYSCALL); /* To go back to user code. */
> }
>
> The comment here seems to indicate the interface is different:
> +       case PTRACE_SYSEMU: /* continue and stop at next syscall, which
> will not be executed */
>
> That would indicate to me that we run SYSEMU to get stopped at the next
> entry, and that call won't be executed (before we even know what it is).

Ok, yes, this is true.

Currently, SYSEMU allows us to switch from SYSEMU to SYSCALL, but the
execution mode for a syscall is determined from which mode was used on
syscall entry; if you use PTRACE_SYSCALL after syscall entry, this syscall is
completed as usual, and next syscall will run as under PTRACE_SYSCALL.

Actually, as a general purpose patch this might be a bit broken, I have to
admit, but it was written for UML's usage at the beginning. On 2.4 it
provided this behaviour automatically, on 2.6 it was fixed to conform to the
same interface.

But I think this is fixable; for the patch itself it should be trivial, the
problem is supporting it in UML: whether the syscall is executed or not, is
determined from the return value of do_syscall_trace(); as easily seen in the
code, the return value is read on syscall entry, and reused even after
running the debugger.

Also, I'm not that happy to change again UML to support yet another
 interface, but if needed it may be done I hope.

I think that this may be basically fixed in UML by using the same syscall
interception even for completing the syscall... at no performance cost.

The only cost would be adding yet another startup test for this new feature -
however, it is greatly outweighted by mainline inclusion.

> Charles

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

-------------------------------------------------------

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