Reputation: 9130
I am implementing an exception handling function using Pin. In my exception handling code, I particularly search for memory access error, say, memory read error and memory write error. I wrote some code below:
BOOL catchSignalTest(THREADID tid, INT32 sig, CONTEXT *ctx, BOOL hasHandler, const EXCEPTION_INFO *pExceptInfo, VOID *v)
{
ADDRINT exptAddr = PIN_GetExceptionAddress(pExceptInfo);
ADDRINT exptAddr = PIN_GetExceptionAddress(pExceptInfo);
FAULTY_ACCESS_TYPE ty = PIN_GetFaultyAccessType(pExceptInfo); <----- ty is unknown type!!!
}
.....
PIN_InterceptSignal(SIGSEGV, catchSignalTest, 0);
What really confuses me is that, even for a typical memory read access error below:
mov eax, [ebx] <--- ebx = 0x01, which makes the read operation failed
The FAULTY_ACCESS_TYPE
of my code above is still UNKNOWN
. Note that according to its definition, I suppose the access type should be FAULTY_ACCESS_READ
.
Am I doning anything wrong here?
Upvotes: 0
Views: 215
Reputation: 33631
Before you call PIN_GetFaultyAccessType
, you probably want to:
(1) call PIN_GetExceptionCode
to get the EXCEPTION_CODE
(2) call PIN_GetExceptionClass
to get the EXCEPTION_CLASS
as the fault access type may only be valid/useful if the class is EXCEPTCLASS_ACCESS_FAULT
At a guess, since you're accessing an odd location [with a 32 bit word fetch], the PIN library may set [probably sets] the x86's hardware "alignment check" (#AC) bit.
Then, you'll get EXCEPTCODE_ACCESS_MISALIGNED
which would explain the results you get for the type (e.g. the alignment gets checked first, before the access). Since it's an alignment exception, the other access type codes don't really fit.
IMO, if the PIN library does not set #AC, then, EXCEPTCODE_ACCESS_MISALIGNED
is kind of a pointless NOP.
You could try various ebx
values like 4 against a known page that you changed the memory protections on (e.g. generate an access exception that you know is not also misaligned).
Upvotes: 1