site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Thanks, Cyrus #include <stdio.h> #include <signal.h> #if defined(__MACH__) #include <sys/_types.h> #include <sys/ucontext.h> typedef struct ucontext os_context_t; #endif #define FROB_EIP void sigtrap_handler(int signal, siginfo_t *info, void *void_context) { os_context_t *context = (os_context_t*)void_context; unsigned int trap; unsigned int eip; #if defined(__MACH__) eip = (context->uc_mcontext->ss.eip); #endif #ifdef FROB_EIP *(&context->uc_mcontext->ss.eip) += 1; #endif } void install_sigtrap_handler() { struct sigaction sa; sa.sa_sigaction = sigtrap_handler; sa.sa_flags = SA_SIGINFO | SA_RESTART | SA_NODEFER; sigaction(SIGTRAP, &sa, NULL); } void test_trap() { __asm__ __volatile__ ( "int3\n\t" #ifdef FROB_EIP ".byte 0x09" #endif ); } int counter; int main(int argc, char** argv) { install_sigtrap_handler(); int i=0; counter = 0; for(i=0; i<10000; i++, counter++) { test_trap(); fprintf(stderr, " i: %d, counter: %d\n", i, counter); } return 0; } On Mar 12, 2006, at 11:43 PM, Eric Albert wrote: On Mar 12, 2006, at 11:25 PM, Cyrus Harmon wrote: -Eric _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... Thanks for the interest in this problem. I have a test case that seems to show some weirdness related to trap handling. It's quite possible that I'm doing something wrong in this test case, but it looks good to me. It can be found below. Ah, here's an interesting thing. If I turn off the EIP frobbing, and only do an INT3, not an INT3 with an extra byte as an error code that my sigtrap handler attempts to skip over, everything is fine. Turn off the #define FROB_EIP to see this behavior. The good news is that, at least from this test case, ITNT3 and sigtrap are reasonably happy, but the bad news is that if one tries to adjust the EIP inside of a sigtrap hanlder, bad things happen. But I would still like to be able to adjust the EIP from within my sigtrap handler. Suggestions? fprintf(stderr, "TRAP! PC: %x, *PC: %x", eip, *((unsigned short*) (eip-1)) ); This may sound a bit sketchy, as it only happens somewhat sporadically, but when it happens, bad things happen. I'm working on an x86 port of a compiler that makes heavy use of trapping in it's runtime environment and things basically seem to work pretty well at this point. My problem is that every now and then, I try to trap with an x86 INT3 (opcode CC) and our SIGTRAP handler takes a look at the byte following the CC, gets the appropriate "arguments" by looking at the instruction data just after the EIP, fixes up the EIP to skip over these arguments and goes on its merry way. This all works well enough, except when it doesn't, which is to say that occasionally it seems that I just walk across the INT3 without the SIGTRAP handler being called, and get a SEGV when the CPU tries to execute the instruction immediately following the INT3, which was supposed to be skipped over by the code that fixes up the EIP in the signal handler. Yes, this is all a bit messy, but the frustrating part is that most of the time this works. Is anyone else seeing instances where INT3 traps aren't being called? I don't think we have any bug reports on this. It'd be great to have one with a reproducible test case, even if it's along the lines of "this shows up about 10% of the time with this test". Any suggestions on where to look in the Darwin sources to see if there's anything amiss? This works fine on Darwin/ppc and, FWIW, {freebsd,linux}/x86 and mostly works on Darwin/x86, but this one thing is causing some rather major problems. Any suggestions or advice on dealing with this would be greatly appreciated. You'd need the kernel source, which I'm afraid isn't available yet for the Intel releases of Mac OS X. You could look at the older Darwin/x86 kernel sources, but enough has changed since then that it wouldn't be helpful. This email sent to site_archiver@lists.apple.com