On Thu, Jan 19, 2017 at 9:40 PM, Sebastian Lackner sebastian@fds-team.de wrote:
On 19.01.2017 20:30, Julian Seward wrote:
Hi Sebastian,
The Valgrind bugtracker also contains three patches I proposed back then. I was hoping that this would speed up the process of getting this fixed, but unfortunately it didn't help much. At many places Valgrind does not yet handle signal registers correctly and doesn't complain - except here, which is really unfortunate because even ignoring would be sufficient to make Wine happy.
Sorry this fell through the cracks. One underlying problem is that, some time back in 2003, I learnt just enough about x86 segment stuff to hack up what's currently in Valgrind, and then promptly forgot about it. So I'm not in much of a position to make an informed judgement now.
That said .. I would be OK with a partial fix which improves Valgrind's SS handling enough to make Wine work, so long as it doesn't create a situation where other cases are silently handled incorrectly. That is, if the fix only moves forwards on the correctness scale, and doesn't introduce any regressions.
On rereading https://bugs.kde.org/show_bug.cgi?id=344139#c1 I see that you have a candidate patch (http://ix.io/gKt, "Correctly handle the SS prefix when explicitly specified.") which appears to have the abovementioned properties. Is that correct?
J
As discussed on IRC, this direction probably makes most sense. In contrast to the other approaches, no special handling for the SS segment is required - nevertheless, we have to initialize some GDT entries to make this work.
I have attached a new series which is hopefully less hacky:
https://bugs.kde.org/show_bug.cgi?id=344139#c3 (*) https://bugs.kde.org/show_bug.cgi?id=344139#c4
(*) On some systems the segment for DS and SS is the same, but initializing twice shouldn't hurt.
For me it fixes the Wine tests (@Austin: Could you confirm?). Please let me know if you have any other suggestions for improvement (either here or on the bugtracker). Thanks!
Best regards, Sebastian
With those two patches on top of r16203, I can run dlls/advapi32/tests/service.c again without the trap 0 occurring
My wine/valgrind branch has one other patch, for https://bugs.winehq.org/show_bug.cgi?id=39097. So I also tried reapplying 4a1629c4117fda9eca63b6f56ea45771dc9734ac, and rerunning dlls/comdlg32/tests/filedlg.c with valgrind, but it still hangs.
So the patches are good for me, but there's still at least one wine and valgrind regression that needs to be investigated.