| Summary: | vex x86->IR: unhandled instruction bytes: 0xCD 0x1 0x90 0x90 | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | acahalan |
| Component: | vex | Assignee: | Julian Seward <jseward> |
| Status: | REPORTED --- | ||
| Severity: | crash | ||
| Priority: | NOR | ||
| Version: | 3.2.1 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Bug Depends on: | |||
| Bug Blocks: | 256630 | ||
|
Description
acahalan
2006-10-12 09:01:54 UTC
BTW, it's not "KDE Devel" at all, but I was forced to pick something. I don't have KDE installed. Wat made you pick KDE Devel? Did you use the generic KDE bug reporting page? or did you use the valgrind one? Why do you expect other problems? I agree that we don't raise the right signal for various int instructions, but as far as I know (b), (c), (f) and (g) are all correct. I believe that (e) and (h) are largely correct, at least for integer registers - there may be issues with floating point registers though, especially for (h). I believe there may be some issues with (d) but it is far more likely to be correct if the signal is correct. Regarding Comment #2: I followed the link from the valgrind page, was made to create an account (which sucks), couldn't log in immediately, then later returned to whatever page that was. It was some "wizard" interface. Regarding Comment #3: It's a bit scary that you don't just jump to the real code. That would be the obvious way to get 100% correct signal frames. I've also seen problems using sigqueue() and longjmp(), but I don't have the testcase handy. I suspect you wound up back at the generic KDE page because you had to go through the account creation - it's a bit of a limitation of the way we are borrowing space in the KDE bug tracker I'm afraid. It shouldn't happen next time as you have an account now... We don't jump to the real code because the real code is in the kernel so we can't! Your program is running on an emulated virtual machine so we have to do many of the things the kernel would normally do on behalf of your emulated process. So the kernel delivers a signal to us (or sometimes, like here, we actually fake the signal ourselves when we encounted an instruction that should generation a signal. We then build a ucontext containg the emulated register values (which I am sure you would prefer to the real register values...) and then run your signal handler under emulation on the virtual machine. By "jump to the real code" I do not mean the kernel code. I mean the untranslated app code at the original memory location, causing a real trap into the kernel from the correct location. I presume you would then catch this on your own stack, copy the stack frame over to the app stack, and continue on with emulation at the app's signal handler code. This way you wouldn't need to built a ucontext yourself, possibly excepting a few adjustments in the stack_t to indicate sigaltstack-related status. (and relocation for stuff like the FPU data pointer of course) Because that's an incredibly complicated and fragile looking solution. Without thinking very hard about it I have no idea whether or not it could be made to work, but it's largely pointless as we have a perfectly good signal delivery mechanism already. Fixing this bug is not rocket science, it just needs a bit of VEX work from Julian to make VEX correctly indicate what signal needs to be raised and valgrind is perfectly capable of doing everything else already. It is possible that there might be some problems with the signal frames we create, but those will be fairly easy to fix if they do turn out to be a problem for you and I think we're getting way ahead of ourselves to worry about them now. |