|
From: Yao Qi <qiy...@cn...> - 2005-11-22 10:43:32
|
I get valgrind-DULLARD.tar.bz2 from, http://www.cs.utexas.edu/~njn/software.html It is a tool based on valgrind-2.1.2, and I want to rewrite it on valgrind(svn). Now, I could pick up all the "STORE"/"LOAD" operations by st->tag == Ist_Store and st->Ist.Tmp.data->tag == Iex_Load. I do not know how to get the address and data for "LOAD"/"STORE" operations in Valgrind. In valgrind-2.1.2, UInstr record a lot of information to get address and data, but I could not find its counterpart in valgrind 3.0.1 or later. When I print all IRs by ppIRStmt, and I could only get part of information I needed. For example on PowerPC, stwu r1,-32(r1) could be translate to, ------ IMark(0x10000440, 4) ------ t1 = GET:I32(124) t2 = GET:I32(4) t3 = Add32(t2,0xFFFFFFE0:I32) PUT(4) = t3 STbe(t3) = t2 "offset" in "GET" confused me very much, and could I calculate data and address by these IRs? I am not sure, so maybe someone of you could clarify it for me. Thanks in advance! -- Regards, Yao ------------ Yao Qi |
|
From: Julian S. <js...@ac...> - 2005-11-22 12:05:48
|
> For example on PowerPC, stwu r1,-32(r1) could be translate to, > > ------ IMark(0x10000440, 4) ------ > t1 = GET:I32(124) > t2 = GET:I32(4) > t3 = Add32(t2,0xFFFFFFE0:I32) > PUT(4) = t3 > STbe(t3) = t2 GET and PUT are for access to the simulated registers. GET:I32(4) gets the value of simulated r1. In this example, GET:I32(124) is not used and will be removed by the IR optimiser. To see loads and stores you need to look at LDbe and STbe. So STbe(t3) = t2 means 'store value of t2 at address t3'. The type of the stored value is the type of t2, which here is I32. J |
|
From: Nicholas N. <nj...@cs...> - 2005-11-22 15:24:24
|
On Tue, 22 Nov 2005, Julian Seward wrote: >> For example on PowerPC, stwu r1,-32(r1) could be translate to, >> >> ------ IMark(0x10000440, 4) ------ >> t1 = GET:I32(124) >> t2 = GET:I32(4) >> t3 = Add32(t2,0xFFFFFFE0:I32) >> PUT(4) = t3 >> STbe(t3) = t2 > > GET and PUT are for access to the simulated registers. > GET:I32(4) gets the value of simulated r1. In this example, > GET:I32(124) is not used and will be removed by the IR optimiser. > > To see loads and stores you need to look at LDbe and STbe. > So STbe(t3) = t2 means 'store value of t2 at address t3'. > The type of the stored value is the type of t2, which here > is I32. And look at Lackey (lackey/lk_main.c in the SVN repository), which does some stuff with loads and stores; look particularly at the parts controlled by the "lk_clo_detailed_counts" variable. Nick |
|
From: Yao Qi <qiy...@cn...> - 2005-11-23 02:53:40
|
On Tue, Nov 22, 2005 at 09:24:13AM -0600, Nicholas Nethercote wrote: > On Tue, 22 Nov 2005, Julian Seward wrote: > > >>For example on PowerPC, stwu r1,-32(r1) could be translate to, > >> > >>------ IMark(0x10000440, 4) ------ > >>t1 = GET:I32(124) > >>t2 = GET:I32(4) > >>t3 = Add32(t2,0xFFFFFFE0:I32) > >>PUT(4) = t3 > >>STbe(t3) = t2 > > > >GET and PUT are for access to the simulated registers. > >GET:I32(4) gets the value of simulated r1. In this example, > >GET:I32(124) is not used and will be removed by the IR optimiser. > > > >To see loads and stores you need to look at LDbe and STbe. > >So STbe(t3) = t2 means 'store value of t2 at address t3'. > >The type of the stored value is the type of t2, which here > >is I32. > > And look at Lackey (lackey/lk_main.c in the SVN repository), which does > some stuff with loads and stores; look particularly at the parts > controlled by the "lk_clo_detailed_counts" variable. lackey record type and count of LOAD, STORE and AluOps, and I could categorise IRs like lackey. The problem is how to collect information of every memory access on run-time, like <LOAD/SORE, DATA, ADDRESS>, any thoughts on this? > > Nick -- Regards, Yao ------------ Yao Qi |
|
From: Nicholas N. <nj...@cs...> - 2005-11-23 14:48:29
|
On Wed, 23 Nov 2005, Yao Qi wrote:
> lackey record type and count of LOAD, STORE and AluOps, and I could
> categorise IRs like lackey.
>
> The problem is how to collect information of every memory access on
> run-time, like <LOAD/SORE, DATA, ADDRESS>, any thoughts on this?
Take a look at Cachegrind. See how in the "Ist_Tmp" case the
"data->Iex.Load.addr" gets passed to addEvent_Dr() where it is saved in
"evt->dataEA" ("EA" is short for "effective address", which is the value
you want). The "Ist_Store" case is similar.
Later in flushEvents() you can see how evt->dataEA is used in calls to
mkIRExprVec_2() and mkIRExprVec_3(), which are then passed to
unsafeIRDirty_0_N() which creates a C call.
Nick
|
|
From: Yao Qi <qiy...@cn...> - 2005-11-24 10:37:53
|
On Wed, Nov 23, 2005 at 08:48:04AM -0600, Nicholas Nethercote wrote:
> On Wed, 23 Nov 2005, Yao Qi wrote:
>
> >lackey record type and count of LOAD, STORE and AluOps, and I could
> >categorise IRs like lackey.
> >
> >The problem is how to collect information of every memory access on
> >run-time, like <LOAD/SORE, DATA, ADDRESS>, any thoughts on this?
>
> Take a look at Cachegrind. See how in the "Ist_Tmp" case the
> "data->Iex.Load.addr" gets passed to addEvent_Dr() where it is saved in
> "evt->dataEA" ("EA" is short for "effective address", which is the value
> you want). The "Ist_Store" case is similar.
Yes, Cachegrind also collect information of memory access, and it did
help me a lot. Thanks for your kind help and great suggestions.
>
> Later in flushEvents() you can see how evt->dataEA is used in calls to
> mkIRExprVec_2() and mkIRExprVec_3(), which are then passed to
> unsafeIRDirty_0_N() which creates a C call.
When I want to display the data of every memory access, I met another problem.
Here is a piece of source code for your reference,
di = unsafeIRDirty_0_N(2, "print_write_data",&print_write_data,
mkIRExprVec_2(st->Ist.Store.addr,st->Ist.Store.data));
addStmtToIRBB (bb, RTStmt_Dirty(di));
"print_write_data" is declared like this,
static void print_write_data (Addr data_addr, HWord data);
When I run it, it display,
vex: priv/host-ppc32/isel.c:554 (doHelperCall): Assertion
`typeOfIRExpr(env->type_env, args[i]) == Ity_I32 || typeOfIREx
pr(env->type_env, args[i]) == Ity_I64' failed.
I dumped the current IR, it is SEbe(0x100100A0:I32) = 0x61:I8, and the
original guest instruction are,
li 10,'a'
stb 10,0(4)
It seems that 0x61:I8 failed in assertion, and what could I do? Do you
think it is acceptable to "promote" I8 to I32?
Could anyone have a look at it and clarify it for me? Thanks in advance!
>
> Nick
>
--
Regards, Yao
------------
Yao Qi
|
|
From: Yao Qi <qiy...@cn...> - 2005-11-23 02:36:36
|
On Tue, Nov 22, 2005 at 11:57:46AM +0000, Julian Seward wrote: > > > For example on PowerPC, stwu r1,-32(r1) could be translate to, > > > > ------ IMark(0x10000440, 4) ------ > > t1 = GET:I32(124) > > t2 = GET:I32(4) > > t3 = Add32(t2,0xFFFFFFE0:I32) > > PUT(4) = t3 > > STbe(t3) = t2 > > GET and PUT are for access to the simulated registers. > GET:I32(4) gets the value of simulated r1. In this example, > GET:I32(124) is not used and will be removed by the IR optimiser. > > To see loads and stores you need to look at LDbe and STbe. > So STbe(t3) = t2 means 'store value of t2 at address t3'. > The type of the stored value is the type of t2, which here > is I32. Thanks for your kind help. Could I get the value of t3 and t2 at run-time further? What I mean is if I could get the run-time value of t2 and t3, I could record the address and data of each memory access. Just like in GDB, stwu r1,-32(r1) is at 0x10000440, (gdb) b *0x10000440 Breakpoint 1 at 0x10000440 (gdb) disassemble 0x10000440 0x10000450 Dump of assembler code from 0x10000440 to 0x10000450: 0x10000440 <main+0>: stwu r1,-32(r1) 0x10000444 <main+4>: mflr r0 0x10000448 <main+8>: stw r31,28(r1) 0x1000044c <main+12>: stw r0,36(r1) End of assembler dump. (gdb) run Breakpoint 1, 0x10000440 in main () (gdb) p/x $r1 $3 = 0xffffe7a0 Now, I could know, STORE data 0xffffe7a0 to address 0xffffe7a0 - 32. Could I do it in valgrind? I want to collect memory access information, and record *every* memory access, like < LOAD/STORE, DATA, ADDRESS >. Any thoughts on this? -- Regards, Yao ------------ Yao Qi |