|
From: Tilman S. <ti...@co...> - 2006-12-30 22:05:15
|
Hi, this mail is a follow-up to Dave Airlie's Thread "an mmaptracer" that he started in March. Unfortunately I don't have that mail's Message-ID, but the thread is available here: http://thread.gmane.org/gmane.comp.debugging.valgrind/5322/focus=3D5322 Nicholas Nethercote [2006-03-08 04:51] > Currently you're passing in t1 to trace_store(). You want to also > pass in t2. You are already almost doing it -- you have three args > in the instrumentation code, but trace_store() only takes two. I don't > think data_expr is what you want, but you're close. Memcheck and/or > Cachegrind must do similar things in places. I've looked through memcheck's and cachegrind's sources and couldn't find code that does this (or something similar). I'm not even sure how to start implementing this. Am I supposed to evaluate the the "Store" expression, by doing something like the following? switch (Store.data.tag) case Const: // use the Const's value case RdTmp: // get the RdTmp's value and use that ... Would I then create a new expression from the data that I gathered? Or is there some way to just "Store.data"? Any help is greatly appreciated. Thanks, Tilman --=20 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? |
|
From: Nicholas N. <nj...@cs...> - 2006-12-30 22:36:18
|
On Sat, 30 Dec 2006, Tilman Sauerbeck wrote: > Hi, > this mail is a follow-up to Dave Airlie's Thread "an mmaptracer" that he > started in March. Unfortunately I don't have that mail's Message-ID, but > the thread is available here: > http://thread.gmane.org/gmane.comp.debugging.valgrind/5322/focus=5322 > > Nicholas Nethercote [2006-03-08 04:51] >> Currently you're passing in t1 to trace_store(). You want to also >> pass in t2. You are already almost doing it -- you have three args >> in the instrumentation code, but trace_store() only takes two. I don't >> think data_expr is what you want, but you're close. Memcheck and/or >> Cachegrind must do similar things in places. > > I've looked through memcheck's and cachegrind's sources and couldn't > find code that does this (or something similar). > I'm not even sure how to start implementing this. > > Am I supposed to evaluate the the "Store" expression, by doing something > like the following? > > switch (Store.data.tag) > case Const: > // use the Const's value > case RdTmp: > // get the RdTmp's value and use that > ... > > Would I then create a new expression from the data that I gathered? Or > is there some way to just "Store.data"? If 'st' is the pointer to the statement, pass st->Ist.Store.addr and st->Ist.Store.data to the called C function (by using mkIRExprVec_2). Both those values are already 'IRExpr's and so you don't have to evaluate them or create new expressions or anything like that. Nb: Make sure you have an up-to-date copy of the trunk from the Subversion repository, the comments in VEX/pub/libvex_ir.h were recently improved and explain how Vex IR works much better now. Nick |
|
From: Tilman S. <ti...@co...> - 2006-12-30 23:15:05
|
Nicholas Nethercote [2006-12-31 09:23]: > On Sat, 30 Dec 2006, Tilman Sauerbeck wrote: >=20 > >this mail is a follow-up to Dave Airlie's Thread "an mmaptracer" that he > >started in March. Unfortunately I don't have that mail's Message-ID, but > >the thread is available here: > >http://thread.gmane.org/gmane.comp.debugging.valgrind/5322/focus=3D5322 > > > >Nicholas Nethercote [2006-03-08 04:51] > >>Currently you're passing in t1 to trace_store(). You want to also > >>pass in t2. You are already almost doing it -- you have three args > >>in the instrumentation code, but trace_store() only takes two. I don't > >>think data_expr is what you want, but you're close. Memcheck and/or > >>Cachegrind must do similar things in places. > > > >I've looked through memcheck's and cachegrind's sources and couldn't > >find code that does this (or something similar). > >I'm not even sure how to start implementing this. > > > >Am I supposed to evaluate the the "Store" expression, by doing something > >like the following? > > > > switch (Store.data.tag) > > case Const: > > // use the Const's value > > case RdTmp: > > // get the RdTmp's value and use that > > ... > > > >Would I then create a new expression from the data that I gathered? Or > >is there some way to just "Store.data"? >=20 > If 'st' is the pointer to the statement, pass st->Ist.Store.addr and=20 > st->Ist.Store.data to the called C function (by using mkIRExprVec_2). Bo= th=20 > those values are already 'IRExpr's and so you don't have to evaluate them= =20 > or create new expressions or anything like that. That sounds nice and easy :) I need to pass the size of the written data type, too, so now the code looks like this: static VG_REGPARM(2) void trace_store(Addr addr, SizeT size, UInt value) { ... } ... IRType arg_ty =3D typeOfIRExpr(bbOut->tyenv, st->Ist.Store.data); IExpr* addr_expr =3D st->Ist.Store.addr; IExpr* size_expr =3D mkIRExpr_HWord(sizeofIRType(arg_ty)); IExpr* data_expr =3D st->Ist.Store.data; unsafeIRDirty_0_N(/*regparms*/ 2, "trace_store", VG_(fnptr_to_fnentry)(trace_store), mkIRExprVec_3(addr_expr, size_expr, data_expr)); That created helper call is then added to the IRSB of course. When I run that code, I get: =20 vex: the `impossible' happened: pushArg(x86): can't handle arg of this type [...] LibVEX called failure_exit(). =3D=3D19009=3D=3D at 0x3800136C: report_and_quit (m_libcassert.c:140) Now when I adjust the code to _not_ pass "size_expr", thus reducing the number of arguments to two, I get: vex: priv/host-x86/isel.c:510 (doHelperCall): Assertion `typeOfIRExpr(env->= type_env, args[i]) =3D=3D Ity_I32' failed. Any idea on that? > Nb: Make sure you have an up-to-date copy of the trunk from the Subversio= n=20 > repository, the comments in VEX/pub/libvex_ir.h were recently improved an= d=20 > explain how Vex IR works much better now. Yeah, I run this on the trunk. Regards, Tilman --=20 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? |
|
From: Nicholas N. <nj...@cs...> - 2006-12-30 23:49:59
|
On Sun, 31 Dec 2006, Tilman Sauerbeck wrote:
> I need to pass the size of the written data type, too, so now the code
> looks like this:
>
> static VG_REGPARM(2) void
> trace_store(Addr addr, SizeT size, UInt value) { ... }
>
> ...
>
> IRType arg_ty = typeOfIRExpr(bbOut->tyenv, st->Ist.Store.data);
> IExpr* addr_expr = st->Ist.Store.addr;
> IExpr* size_expr = mkIRExpr_HWord(sizeofIRType(arg_ty));
> IExpr* data_expr = st->Ist.Store.data;
>
> unsafeIRDirty_0_N(/*regparms*/ 2, "trace_store",
> VG_(fnptr_to_fnentry)(trace_store),
> mkIRExprVec_3(addr_expr, size_expr, data_expr));
>
> That created helper call is then added to the IRSB of course.
> When I run that code, I get:
>
> vex: the `impossible' happened:
> pushArg(x86): can't handle arg of this type
> [...]
> LibVEX called failure_exit().
> ==19009== at 0x3800136C: report_and_quit (m_libcassert.c:140)
Args passed to C functions have to be word-sized. data_expr will not always
be word-sized. I think you need to switch on the data_size and convert the
value to word-size using the appropriate unary casts (16Uto32, etc).
> Now when I adjust the code to _not_ pass "size_expr", thus reducing the
> number of arguments to two, I get:
>
> vex: priv/host-x86/isel.c:510 (doHelperCall): Assertion `typeOfIRExpr(env->type_env, args[i]) == Ity_I32' failed.
>
> Any idea on that?
Hmm, not sure about that one, again it's complaining that one of the
arguments isn't 32 bits, but I'm not sure why.
Nick
|
|
From: Julian S. <js...@ac...> - 2006-12-31 00:19:31
|
> > vex: the `impossible' happened:
> > pushArg(x86): can't handle arg of this type
> > [...]
> > LibVEX called failure_exit().
> > ==19009== at 0x3800136C: report_and_quit (m_libcassert.c:140)
>
> Args passed to C functions have to be word-sized. data_expr will not
> always be word-sized. I think you need to switch on the data_size and
> convert the value to word-size using the appropriate unary casts (16Uto32,
> etc).
So you'll need to establish sizeof(void*) in your tool and widen all the
args to that. Something like the following function might be handy:
/* U-widen 8/16/32 bit int expr to 32. */
static IRExpr* widenUto32 ( IRExpr* e )
{
switch (typeOfIRExpr(irsb->tyenv,e)) {
case Ity_I32: return e;
case Ity_I16: return unop(Iop_16Uto32,e);
case Ity_I8: return unop(Iop_8Uto32,e);
default: vpanic("widenUto32");
}
}
Naturally you'll need a second one for 64-bit platforms.
J
|
|
From: Tilman S. <ti...@co...> - 2006-12-31 00:24:41
|
Nicholas Nethercote [2006-12-31 10:34]:
> On Sun, 31 Dec 2006, Tilman Sauerbeck wrote:
>=20
> >I need to pass the size of the written data type, too, so now the code
> >looks like this:
> >
> >static VG_REGPARM(2) void
> >trace_store(Addr addr, SizeT size, UInt value) { ... }
> >
> >...
> >
> >IRType arg_ty =3D typeOfIRExpr(bbOut->tyenv, st->Ist.Store.data);
> >IExpr* addr_expr =3D st->Ist.Store.addr;
> >IExpr* size_expr =3D mkIRExpr_HWord(sizeofIRType(arg_ty));
> >IExpr* data_expr =3D st->Ist.Store.data;
> >
> >unsafeIRDirty_0_N(/*regparms*/ 2, "trace_store",
> > VG_(fnptr_to_fnentry)(trace_store),
> > mkIRExprVec_3(addr_expr, size_expr, data_expr));
> >
> >That created helper call is then added to the IRSB of course.
> >When I run that code, I get:
> >
> >vex: the `impossible' happened:
> > pushArg(x86): can't handle arg of this type
> >[...]
> > LibVEX called failure_exit().
> >=3D=3D19009=3D=3D at 0x3800136C: report_and_quit (m_libcassert.c:140)
>=20
> Args passed to C functions have to be word-sized. data_expr will not=20
> always be word-sized. I think you need to switch on the data_size and=20
> convert the value to word-size using the appropriate unary casts (16Uto32=
,=20
> etc).
This is what I did:
switch (arg_ty) {
case Ity_I8:
IRTemp t =3D newIRTemp(bbOut->tyenv, Ity_I32);
addStmtToIRSB(bbOut,
IRStmt_WrTmp(t, IRExpr_Unop(Iop_8Uto32, data_expr)));
data_expr =3D IRExpr_RdTmp(t);
break;
case Ity_I16:
/* ditto, with s/8Uto32/16Uto32/
}
=2E. and it seems to work :)
Will run a more complete test tomorrow.
Thanks for your help!
Regards,
Tilman
--=20
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
|