|
From: Eric P. <eri...@wa...> - 2006-02-13 09:29:26
|
Julian Seward wrote: >>>When you say "valgrind fails", exactly what happens? >> >>==14133== Using valgrind-3.1.0, a dynamic binary instrumentation framework. > > > Ah. 3.1.0. That wasn't clear from before. Sure, I can repro the crash > with 3.1.0, but I guess something or other got fixed after 3.1.0, since > the program runs OK with the current trunk (pre 3.2.0) sources, as I said. > > So I suggest you dump 3.1.0 and check out and build the trunk, which is > very easy: see http://www.valgrind.org/downloads/repository.html > and let us know if you find any problems with that. with svn trunk things are way better ;-) But, not yet 100% correct. Basically, with the attached patches, Wine works (almost - see below) correctly, even for SEH: 1/ trapno in sigframe (vg-trapno.diff) (already posted in the bug database, but enhanced from previous post). This patch sets the trapno field in sigframe structure. 2/ handling ESP change in sig handler (vg-sig.diff) This patch tries to fetch the cases where a sig handler changes ESP in ucontext, and lets V know about it. Ok, it's a bit black magic, but it prevents a tons of warnings. I only wrote it for old signal frame signatures, but it's rather straightforward to implement it to RT signal handlers. 3/ disabled support for tkill (vg-tkill.diff) This patch (partly) reenables tkill syscall under x86-linux. Basically, Wine is made to run either under (NPTL) pthread support, or old kernel thread support. We use tkill, which is transparent whatever the thread system we're running on (pthread or kthread). 4/ missing opcodes in X86 emulation (vg-vex.diff) Wine uses some implemented opcodes (push / pop of cs, ds, es, fs, and gs), as well as iret. The first ones were quite simple to implement. For iret, I put something together, which is wrong from emulation point of view: - eflags is not correctly restored, I simply copied the popf stuff - it doesn't restore cs With those patches applied to V, I can now run simply SEH programs in Wine under memcheck. However, this still generates some warnings (invalid read/write of size 4), and for some of them are in code reading/writing values onto the stack, which looks like V is still fooled with all the tricks we do in Wine. Comments welcome! A+ -- Eric Pouech |