|
From: Julio M. M. V. <jm...@ac...> - 2007-10-19 09:24:41
|
Hello,
I'm currently writing an instrumentation tool for a class assignment
using Valgrind. I'm interested in tracking all memory loads and
stores to later depict them in some form of graph. So far I've added
the necessary "hooks" to Store statements and Load expressions to the
guest code. For example, this is for the Store:
UInt size = sizeofIRType(typeOfIRExpr(sb->tyenv, st-
>Ist.Store.data));
argv = mkIRExprVec_2(mkIRExpr_HWord((HWord)st->Ist.Store.addr),
mkIRExpr_HWord(size));
di = unsafeIRDirty_0_N(1, "trace_mem",
VG_(fnptr_to_fnentry)(&trace_mem),
argv);
addStmtToIRSB(sb, IRStmt_Dirty(di));
But I can't find the correct way to interpret the address expressions
I pass to the trace_mem function. How am I supposed to process the
value of Ist.Store.addr (or the address of the Load in its case) to
get the real address where the guest program is going to access?
I also have this:
static inline
Addr
expr_to_addr(IRExpr* e)
{
Addr addr;
tl_assert(isIRAtom(e));
if (e->tag == Iex_Const) {
switch (e->Iex.Const.con->tag) {
case Ico_U1: addr = e->Iex.Const.con->Ico.U1; break;
case Ico_U8: addr = e->Iex.Const.con->Ico.U8; break;
case Ico_U16: addr = e->Iex.Const.con->Ico.U16; break;
case Ico_U32: addr = e->Iex.Const.con->Ico.U32; break;
case Ico_U64: addr = e->Iex.Const.con->Ico.U64; break;
default: tl_assert(0);
}
VG_(printf)("constant: %p\n", (void*)addr);
} else if (e->tag == Iex_RdTmp) {
/* XXX What here? */
} else
tl_assert(0);
return addr;
}
I *think* the case for Iex_Const is correct (I saw some similar code
in another Valgrind tool), but what do I have to do in the
Iex_RdTmp? Is it there any other simpler way to achieve this?
Thank you,
--
Julio M. Merino Vidal <jm...@ac...>
|
|
From: Julio M. M. V. <jm...@ac...> - 2007-10-20 22:22:36
|
On Oct 19, 2007, at 11:24 AM, Julio M. Merino Vidal wrote: > Hello, > > I'm currently writing an instrumentation tool for a class assignment > using Valgrind. I'm interested in tracking all memory loads and > stores to later depict them in some form of graph. So far I've added > the necessary "hooks" to Store statements and Load expressions to the > guest code. For example, this is for the Store: > > UInt size = sizeofIRType(typeOfIRExpr(sb->tyenv, st- >> Ist.Store.data)); > argv = mkIRExprVec_2(mkIRExpr_HWord((HWord)st- > >Ist.Store.addr), > mkIRExpr_HWord(size)); > di = unsafeIRDirty_0_N(1, "trace_mem", > VG_(fnptr_to_fnentry)(&trace_mem), > argv); > addStmtToIRSB(sb, IRStmt_Dirty(di)); > > But I can't find the correct way to interpret the address expressions > I pass to the trace_mem function. How am I supposed to process the > value of Ist.Store.addr (or the address of the Load in its case) to > get the real address where the guest program is going to access? OOOK, I reply myself after having read memcheck's code for a while. That conversion of the address to an HWord is bogus. Removing that and leaving the addr parameter alone makes things work as expected :-) Sorry for the noise, -- Julio M. Merino Vidal <jm...@ac...> |
|
From: Nicholas N. <nj...@cs...> - 2007-10-21 23:02:17
|
On Sun, 21 Oct 2007, Julio M. Merino Vidal wrote: >> I'm currently writing an instrumentation tool for a class assignment >> using Valgrind. I'm interested in tracking all memory loads and >> stores to later depict them in some form of graph. So far I've added >> the necessary "hooks" to Store statements and Load expressions to the >> guest code. For example, this is for the Store: >> >> UInt size = sizeofIRType(typeOfIRExpr(sb->tyenv, st- >>> Ist.Store.data)); >> argv = mkIRExprVec_2(mkIRExpr_HWord((HWord)st- >>> Ist.Store.addr), >> mkIRExpr_HWord(size)); >> di = unsafeIRDirty_0_N(1, "trace_mem", >> VG_(fnptr_to_fnentry)(&trace_mem), >> argv); >> addStmtToIRSB(sb, IRStmt_Dirty(di)); >> >> But I can't find the correct way to interpret the address expressions >> I pass to the trace_mem function. How am I supposed to process the >> value of Ist.Store.addr (or the address of the Load in its case) to >> get the real address where the guest program is going to access? > > OOOK, I reply myself after having read memcheck's code for a while. > That conversion of the address to an HWord is bogus. Removing that > and leaving the addr parameter alone makes things work as expected :-) I'm glad to hear you worked it out. Vex's IR does take some time to understand -- C's cumbersome support for tagged unions doesn't help -- but everything is done for a reason, and it does make sense if you stare at it long enough :) Nick |