On Mon, Jul 23, 2012 at 8:00 PM, Josef Weidendorfer
<josef.weidendor...@gmx.de> wrote:
> Am 23.07.2012 19:08, schrieb Mikael Jansson:
>> + VG_(printf)("S %p\n", ist->Store.addr)
>> ...
>> Have I misunderstood how ist->Store.addr is supposed to be used,
>
> Yes. IRStmt.Store.addr is of type IRExpr*. You are printing out
> the address of a structure used for the VEX IR while instrumentation
> of a code block is done. The code behind never was executed yet!
Ah, thanks!
> To get to the real address, you have to catch it while code is
> executed, e.g. by instrumenting a call to your own function when
> a store is done. See lackey for how to do that.
Would that be the trace_...() instructions in Lackey? Because, output
from --tool=lackey --trace-mem=yes looks like this:
I 040fc67c,7
L 041b88e0,4
S be95f5d0,4
I 040010c0,2
AFTER strdup, memory at 0x804B008 has contents h
I 040010c2,1
L be95f5d0,4
I 040fc683,1
The line in the middle is output by my client program, that does a
strdup("hello") and prints the address. strdup() should use some sort
malloc() underneath, right? However, searching for the address I got,
0x804B..., yields no results in the entire instrumentation log.
Or did I misunderstand you, and the addresses printed out by
trace_load() / trace_store() / trace_instr() are still just IRExpr
pointers?
Thanks,
Mikael
--
Mikael Jansson
http://mikael.jansson.be
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
