|
From: Tom H. <th...@cy...> - 2004-08-26 09:00:31
|
In message <254...@we...>
Jeroen N. Witmond <jn...@xs...> 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 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.
> Also, in the case of a SIGSEGV, Valgrind is quite capable to set the
> user's EIP in fields:
>
> - ((ucontext_t*)context)->uc_mcontext.gregs[REG_EIP], where 'void*
> context' is the third argument to the sa_sigaction in struct sigaction.
> 'ucontext_t' is declared by '#include <ucontext.h>'. Just now I have
> verified that this field is also set correctly by Valgrind in the case of
> a SIGFPE.
>
> - ctx.eip, where 'struct sigcontext ctx' is the undocumented second
> argument to the sa_handler in struct sigaction.
I know all that. Are you saying that valgrind is already doing so? or
just that it should be doing so?
> [In the case of a SIGSEGV, siginfo->si_addr contains the address of the
> memory that cannot be accessed, not the address of the instruction doing
> the accessing. Not verified under Valgrind.]
Indeed it should, and I believe it will do. There is no translation
done on si_addr so you will get the address the kernel reports, but
for a SEGV that is fine as that is the address in your program.
It won't be the same address as when run outside of valgrind of
course, but that's because your data will probably be laid out
differently in memory. It will be the address your program tried
to read from.
> 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...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|