Re: INT3 not calling SIGTRAP handler?
Re: INT3 not calling SIGTRAP handler?
- Subject: Re: INT3 not calling SIGTRAP handler?
- From: Cyrus Harmon <email@hidden>
- Date: Mon, 13 Mar 2006 11:13:09 -0800
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?
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
fprintf(stderr, "TRAP! PC: %x, *PC: %x", eip, *((unsigned short*)
(eip-1)) );
#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:
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.
-Eric
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden