|
From: Alex B. <ker...@be...> - 2006-11-15 16:11:27
|
Hi,
I have a program that seems to be behaving differently in valgrind
(latest SVN code) to being run normally. My program has a signal handler
which to handle integer overflow conditions. The code looks roughly
like:
void arithmeticSigHandler(int sigNum, siginfo_t *siginfo, void *stuff)
{
ucontext_t *uctx = (ucontext_t *)stuff;
mcontext_t *ctx = (mcontext_t *)&(uctx->uc_mcontext);
//
// Read the faulting instruction so we can check if the fault was
// a signed or unsigned divide.
//
unsigned char instOpcode = *((char*)ctx->gregs[REG_RIP]);
unsigned char instModRM = *((char*)(ctx->gregs[REG_RIP]+1));
fp fprintf(stderr,"rip 0x%lx: instOpcode = 0x%x, ModRM = 0x%x\n",
ctx->gregs[REG_RIP], instOpcode, instModRM);
if(instOpcode == 0xF7) // check its a divide
{
However under valgrind it fails the check and falls through to some
debug code for bad SIGFPE's. The run with the fprintf give the following
output:
Test 5
rip 0x702277f2: instOpcode = 0x8b, ModRM = 0x55
==15666==
==15666== Uninitialised byte(s) found during client check request
But attaching to gdb at the point it gets confused:
...
#15 0x00000000702dbb9f in arithmeticSigHandler (sigNum=8,
siginfo=0x2a960108c8, stuff=0x2a96010798)
#16 <signal handler called>
#17 0x00000000702277f5 in subjectInterpreter_sdiv ()
(gdb) frame 17
#17 0x00000000702277f5 in subjectInterpreter_sdiv ()
(gdb) x/1i $pc
0x702277f5 <subjectInterpreter_sdiv>: idiv %ebx
(gdb) x/5b $pc
0x702277f5 <subjectInterpreter_sdiv>: 0xf7 0xfb 0x89 0x45
0xf0
It looks like the pc the valgrind supplies is a few bytes off what the
core would indicate (and what would happen in real life).
(gdb) x/5b 0x702277f2
0x702277f2: 0x8b 0x55 0xe8 0xf7 0xfb
Any ideas what could be causing that?
I'm running valgrind with the following options:
/usr/local/bin/valgrind --leak-check=full
--vex-iropt-precise-memory-exns --smc-check=all --db-attach=yes
--db-command="/usr/local/bin/gdb -nw %f %p"
For completeness running outside of valgrind I get:
Test 5
rip 0x702277f5: instOpcode = 0xf7, ModRM = 0xfb
Which behaves as expected.
--
Alex, homepage: http://www.bennee.com/~alex/
Think big. Pollute the Mississippi.
|