Blaisorblade wrote:
On Friday 12 November 2004 21:05, Bodo Stroesser wrote:

Attached are several patches. Four of them (patch-2.6.*-skas-v7-*)
implement PTRACE_SYSEMU_SINGLESTEP in the host. They are based on
linux-2.6.7-vanilla + host-skas3-2.6.7-v7.patch (resp. the 2.6.9 versions).
The "-reorganize" patches are a rework of the current patch without
changing the functionality. The "add-SYSEMU_SINGLESTEP" then implement the
new features. Please note: the differences between 2.6.7 and 2.6.9 are
dependent on the different handling of syscall singlestepping in the two
versions.


To have UML using the new feature, there are two further patches named
patch-SYSEMU_SINGLESTEP-*. They are based on linux-2.6.9-vanilla +
all bb2-patches + patch-sysemu-tt + patch-fix-uml-hang-on-2.6.9-host.
To have all the patches complete, the latter two are attached also.


I tested on host 2.6.7 and host 2.6.9 with SKAS and TT mode. Currently I
don't know any problem with it.

I have a problem... in recent host kernels, isn't SINGLESTEP also trapping for syscall instructions?
Yes. IIRC, this feature was included with i386 2.6.9. I'm sure 2.6.7 doesn't
have it, 2.6.9 has.
The difference between the host versions are the reason for the different
reorganize- and add- patches for 2.6.7 and 2.6.9.
But, please, tell me, what problem do you see? SYSEMU_SINGLESTEP is a new
function, that does SYSCALL_TRACE on syscalls and SINGLESTEP on all other
instructions. The function is added without changing the previous functions.
If available, the UML-kernel my use the new function, but users on UML
shouldn't see any changed behavior.
By the way: they also don't see the differences between host 2.6.7 and 2.6.9
regarding syscall-singlestepping.


Also, you say that SINGLESTEP_SYSEMU does automatic syscall overwriting with -1 or emulates that - I suspect it being in the reorganize patches, but you don't mention it in the changelogs here, only about the UML patches.
No. The overwrite is in the "add-" patches. The "reorganize-" patches are
intended to *only* reorganize SKAS3-V7 without changing any little bit of
its behavior. Everything else I would call an error.
But it would be easy to split the "add-" patches into an "overwrite-" and
an remaining "add-" patch.
I only wanted to make clear, that UML must not rely on overwriting done by
the host, unless it can detect the host to have a skas-sysemu-patch with
overwriting enabled. My idea was to take availability of SYSEMU_SINGLESTEP
as flag, that the host *will* do overwriting.


So, I'd personally accept only the -reorganize ones and hold on the rest - which is probably achieved with mainline SINGLESTEP fixes in 2.6.9 (or which could be discussed).


Sorry for being so late (I'd say "Call me a lamer" :-) ) in discussing this, but I hadn't the time to study patches and realize this.

Bodo




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
User-mode-linux-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Reply via email to