https://bugs.kde.org/show_bug.cgi?id=435665
--- Comment #9 from Julian Seward <jsew...@acm.org> ---
So .. I had an idea about how to get the annotations right. Problem is, it's a
nasty hack (although simple), and I had hoped that the passage of a bit of time
would cause me to think of something cleaner. But nothing came to mind, so
here it is. I *think* it'll work, but it needs implementing and testing, to
check that if you do pass undefined values to the accelerator, you do actually
get a Memcheck error.
The basic idea is for your helper function -- the one that copies 128 bytes [or
whatever] to the accelerator -- to return a fake return value. At present it
doesn't return anything. Specifically, you change the helper to return a UWord
and that UWord should be (for example) zero. Then, add a fake use of the fake
value, in a way that will cause Memcheck to test it, as follows. Furthermore
this fake use must not be something that IR optimisation can later remove.
On the IR side (in guest_ppc_toIR.c), you allocate an IRTemp of type I64
(assuming 64-bit only operation) to receive the fake value, and set the
IRTemp::tmp field to be that temp. Also for the IRDirty structure, you must
set mFx/mAddr/mSize so as to declare the memory area it is reading.
Immediately after emitting the IRDirty (in guest_ppc_toIR.c), place an
IRStmt_Exit that uses the fake return value. Something very similar to this:
stmt( IRStmt_Exit(
binop(Iop_CmpNE64, fake_return_val_tmp, mkU64(0)),
Ijk_SigTRAP,
mode64 ? IRConst_U64(cia) : IRConst_U32((UInt)cia),
OFFB_CIA
));
where cia is the current instruction address (is often passed around, see (eg)
do_trap in guest_ppc_toIR.c).
The effects of this trickery are as follows:
(1) the above stmt() asks the IR to exit, asking Valgrind to hand the program a
SIGTRAP at this point, if the fake return value is nonzero, however ..
(2) .. that never happens, because your helper always returns zero.
(3) Memcheck will believe that any undefinedness in the area read by the helper
will be propagated through to the fake return value, and will generate
instrumentation to cause that to happen.
(4) Memcheck will instrument the IRStmt_Exit to check the definedness computed
by (3) and emit an error if the fake return value contains any undefined
bits. Hence you get the warning we want.
(5) We note that the IR optimisation passes do not know what value the helper
call will return. Hence we are guaranteed that they can't optimise away
the IRStmt_Exit and its associated check.
Bad, huh?! I wish there were a cleaner way.
I suggest you test it at least as follows:
(a) check that, if the memory area is fully defined, no error is printed.
(b) check that, if the memory area contains even one undefined bit, an error is
printed.
(c) check that, if the helper function does return nonzero, then you really do
get SIGTRAP synthesised at the instruction. Not that this is important,
but just as a kind of sanity check.
Good luck! I am happy to look at patches, etc, as ever.
--
You are receiving this mail because:
You are watching all bug changes.
