|
From: Julian S. <js...@ac...> - 2004-08-26 12:27:23
|
> > As a result the faulting instruction will always be in a different > > place when running under valgrind. In particular in this case the > > fault is probably occurring in one of the helper routines which is > > used to handle division operations, hence the reason why the address > > is inside stage2 as that is where the helper routines are. > > Hmm? I would have expected that the simulated environment created by > Valgrind (CPU and parts of Linux/libc) behaves the same as the environment > being simulated. Huh? That was never a design goal, and isn't achievable without significant performance overheads. What you are asking for is 'precise exceptions', where, after an instruction takes a fault, in this case a FP exception, the simulated machine's register state is identical to what a real machine would have. This isn't a design goal and isn't likely to become one in future. Valgrind approximately attempts to supply a POSIX-compliant environment in which programs can run -- that's really the design goal. I'm sure that looking at machine registers following an exception isn't POSIX compliant -- POSIX doesn't even guarantee precise exceptions, AIUI. Let alone have any notion of machine registers. > Should I create a bug report for this problem? No. Future valgrinds may optimise code more aggressively than at present, which will likely make this problem worse rather than better. Even at present, Valgrind only guarantees to update the integer/FP/SSE/ register/flag state at each jump, so at an exception you will usually be seeing machine state which is many instructions out of date. J |