|
From: Eric P. <eri...@wa...> - 2006-02-25 09:18:16
|
A summary of where we stand for making Valgrind and Wine work well
together. The starting point is V 3.1.0 and Wine 0.9.7.
First of all (reminder) V & Wine now work (mostly) out of the box together.
Here's a list of (known) problems faced:
a/ missing support for some ioctl's (HDMA, serial). Added to V (now in
branch, at least of x86)
b/ missing support for tkill syscall. Added to V (now in branch), Wine
fixed to use the better tgkill syscall (0.9.8)
c/ some missing instrumentation of Wine (regarding stack manipulation).
Wine fixed (0.9.8)
d/ possibility to change EIP in signal handler. Added to V (now in
branch, for x86).
e/ trapno is not passed in signal handlers. A hacky patch proposed, and
rightfully rejected. Solution in sight (Tom Hughes), not yet in branch.
f/ missing instruction emulation in VEX (x86, and likely amd 64). Wine
needs:
push/pop [ds,es,ss]
iret (on 32bit intercall, cs not changed)(*)
int 3
cli/sti
(*) actually, Wine would require much more for 16bit emulation, but
I don't think it's reasonable, nor a short term goal, to use V &
Wine for 16bit code.
The push/pop code was easy to fix (it's already written). However
iret will be a bit trickier (I have a dirty hack for iret and int 3,
but likely Julian would rather do it himself ;-). We can try to get
rid of the cli/sti pair.
g/ missing stack backtrace information
As already explained, the first thread of a process is handled
as follows: it starts using the stack created from the process
creation (from Unix). As the process may require a larger stack
(from the Windows definition of the PE header), the Wine loader
always create a second stack at the loader startup, and switch
execution to that second stack when calling the PE module entry
point.
The outcome of this, from a V point of view, is that we get two
stacks (values are important):
- first stack at 0xBE??????
- second stack at 0x20?????? (ie below the first one).
The second stack is declared to V by Wine.
When V needs to print a backtrace (for any issue), in
get_StackTrace2 there's a test:
if (fp_min + VG_(clo_max_stackframe) <= fp_max) {
Here fp_min gets its value from the second stack (in the
0x20?????? area, and fp_max in the 0xbe?????? area). The outcome
is that no backtrace is generated :-/. Trying to remove the test
(or increase the max_stackframe value) provides some other
issues as not all the area in the 0x20????? - 0xbe000000 is
mapped, hence having a some crashes.
This one is a bit more hairy to fix. I have a patch that mixes
the max_stackframe test, with some extra test about the stacks
that are known by V (and checking that info for the backtrace
really points to the stack). But since V doesn't make use of
this information, it must be for good reasons.
The net result of this is:
- because of g/, we cannot get a full backtrace of an issue found by V.
Currently, we disabled the offending test in get_StackTrace2 pointed out
in g. With the listed side effects (crashes), and we'd like to have
something working out of the box (from the V branches)
- because of e/ and f/, we cannot use Wine and V on programs triggering
exceptions (the missing parts in e/ and f/ are only used in those
occasions).
I'd really like to see e/, f/ and g/ fixed. Let me know if you need some
help.
The good side of the story:
- we ran the regression tests (from the Wine regression test suite) on 5
DLLs under V, and fixed something like 15 potential issues and bugs
(even if some tests don't work under V yet)
- that's worth going further and run the full Wine regression tests under V.
A+
--
Eric Pouech
|