DWS Externals progress
I’ve been working on the stub-building JIT for external routines in DWS lately, and I just checked in a bunch of updates. The JIT will currently handle parameters of most basic types, and return values of integer, enumerated, or object types. (Still working on the rest.) So it’s not complete yet, but it’s getting there.
One thing I’ve run into trouble with, though: A JIT produces code as data. The OS has a security feature called DEP (Data Execution Prevention) that’s supposed to keep you from executing data as code accidentally (or as a victim of a hack attempt). When it’s turned on, things mostly work since I’ve marked the resulting code as executable, but if it hits an exception handler, it kills the process.
I’ve checked all the obvious things, (multiple times!) and by everything I can tell, it should be working. And yet DEP still kills the process in this specific case, so there’s something I must be missing.
I asked on Stack Overflow, and didn’t get any useful responses. I asked in the forums, and got one lead I’m still working on running down, but nothing yet. I’ve reached out to compiler guys and OS engineers at Microsoft, and gotten nothing useful. Apparently this is a very difficult problem for some reason.
If anyone reading this has any idea what’s going on, please let me know. (And again, I’ve checked all the obvious things, multiple times. Please don’t tell me to make sure to mark the memory page as executable, for example.)
Did you try using your own exception handled with AddVectoredExceptionHandler() as proposed by Nowayz in SO ?
We discussed that in a chat room, and basically that wouldn’t have worked unless I reimplemented essentially the entire SEH system. Not what I’m looking for.
You can intercept the exception, then quickly search for the code portion, and act as expected.
AFAIK this is what SpireMonkey JIT does.
This would not work, for various reasons. First, it’s difficult to simulate unwinding the stack in Win32 code without actually unwinding the stack and running through the exception chain. Second, when an exception is raised, it could be handled before reaching my stub on the stack, which again is difficult to determine without actually running through the exception chain. And third, even if the first two issues could be resolved, running cleanup out-of-order is a bad idea, because it could cause an interface-typed variable to be freed early, which an exception handler above it in the stack might be expecting to reference.
As I pointed out in the chat with him, my program’s problem is that DEP thinks my exception handlers are not valid SEH records for some reason. It’s not that I haven’t reimplemented SEH.
I read your SO thread with interest when it was first posted. You seem to have been very thorough! I have no suggestions, sorry, just want to say it’s interesting stuff and to wish you good luck solving it.
It seems that such information is closed/restricted. May be undocumented API.