|
From: David M. <dm...@gm...> - 2005-11-18 07:05:18
|
Hi everyone,
I and a colleagure are attempting to write a simple Valgrind tool that
prints out the PC of every instruction executed, the address of every store
to memory, and the address of every load to memory. I am running into an
issue where the addresses I see from my tool don't seem to match up with th=
e
addresses I see in gdb or when using logrind 2.
For example, I followed the example of the cachegrind source code and
iterate over all IRStmt * in the incoming basic block. I then have the code
switch(st->tag) {
case Ist_IMark: {
Addr instrAddr =3D (Addr) ULong_to_Ptr(st->Ist.IMark.addr);
and I add a new statement to the BB that passes a list with
mkIRExpr_HWord(instrAddr) to a callback which then prints the instrAddr wit=
h
a VG_(message). believe this should print out the PC for the instruction.
The problem I see is that in gdb on a Linux 2.4 machine is that each PC has
a PC starting with 0x800... (as expected). My tool reports each PC starts
with 0x3A966F... . The logrind 2 tool of C. January agrees with gdb.
Is there some kind of function I need to call to map instrumented addresses
to host addresses? I am seeing similar disreprancies for the memory
addresses of loads and stores.
Thanks very much,
-David Molnar
|
|
From: Julian S. <js...@ac...> - 2005-11-18 13:46:01
|
> switch(st->tag) {
> case Ist_IMark: {
> Addr instrAddr = (Addr) ULong_to_Ptr(st->Ist.IMark.addr);
>
> and I add a new statement to the BB that passes a list with
> mkIRExpr_HWord(instrAddr) to a callback which then prints the instrAddr
> with a VG_(message). believe this should print out the PC for the
> instruction. The problem I see is that in gdb on a Linux 2.4 machine is
> that each PC has a PC starting with 0x800... (as expected). My tool reports
> each PC starts with 0x3A966F... . The logrind 2 tool of C. January agrees
> with gdb.
That all sounds plausible. Why don't you send your entire instrumentation
function; then we can stare at it and see if there is anything obviously
wrong.
J
|
|
From: Julian S. <js...@ac...> - 2005-11-18 14:04:39
|
> > instruction. The problem I see is that in gdb on a Linux 2.4 machine is > > that each PC has a PC starting with 0x800... (as expected). My tool > > reports each PC starts with 0x3A966F... . The logrind 2 tool of C. > > January agrees with gdb. Another thing is, V's address space layout isn't necessarily going to be the same as when running natively. Use flags -d -d (twice) to see the actual memory layout at client startup; that will tell you where the executable/.so's really are. J |
|
From: Nicholas N. <nj...@cs...> - 2005-11-18 14:33:43
|
On Fri, 18 Nov 2005, Julian Seward wrote: >>> instruction. The problem I see is that in gdb on a Linux 2.4 machine is >>> that each PC has a PC starting with 0x800... (as expected). My tool >>> reports each PC starts with 0x3A966F... . The logrind 2 tool of C. >>> January agrees with gdb. > > Another thing is, V's address space layout isn't necessarily going to be > the same as when running natively. Use flags -d -d (twice) to see the > actual memory layout at client startup; that will tell you where the > executable/.so's really are. The code addresses for the main executable should be the same, at 0x8048000 and beyond for x86/Linux. Those in shared objects will probably be in different locations, though. The data addresses should be more or less the same for accesses to the stack and to static data from the main executable. Other data accesses may move around, though. Nick |
|
From: David M. <dm...@gm...> - 2005-11-19 08:30:06
|
On 11/18/05, Julian Seward <js...@ac...> wrote: > > > Another thing is, V's address space layout isn't necessarily going to be > the same as when running natively. Use flags -d -d (twice) to see the > actual memory layout at client startup; that will tell you where the > executable/.so's really are. Thanks! It looks like this clears up some of the confusion -- the 0x3A... addresses turn out to correspond to ld-2.2.3.so <http://ld-2.2.3.so> . Then later I see addresses starting with 0x80.. as expected. I think I may just be seeing more PCs from my tool than from gdb. I will double-check the load and store addresses I was seeing, as well= . If I see any more problems I will let you all know and post my instrumentation routine. -David Molnar |