|
From: Nicholas N. <nj...@ca...> - 2004-08-26 09:14:14
|
On Thu, 26 Aug 2004, Tom Hughes wrote: >> 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. Any deviation may (and hence one day will) make the >> program being tested behave differently when run with or without Valgrind, >> reducing its effectiveness. > > The problem is that there is not a one-one (or even a one-many) mapping > from instructions in the original program to JITed instructions Hmm, that's not really true; there is a one-many mapping from original-->JITted instructions. The INCEIP UCode instruction marks the boundaries. > so it isn't clear which instruction in your program valgrind should make > si_addr point to as it doesn't record which instruction in your program > caused each instruction in the JITed code to be generated, and it might > not even be a single instruction. >> Should I create a bug report for this problem? > > You are welcome to do so, but I don't think it's fixable. It's even > harder than filling in the right FP state (which we don't do) or allowing > the state to be modified (which we don't do). There are already bugs > for those things... It's unclear to me what the right thing to do here is. So here's a question: Jeroen, how did you discover this? Is this behaviour causing problems for you in a real program? If so, can you explain how/why? And would changing the behaviour in the way you say fix the problem? Thanks. N |