Re: [Valgrind-users] Understanding guest_bytes_addr

[Stephen T. <st...@to...>]

Thanks. I think I am beginning to understand. I see how I need to make
repeated calls to LibVEX_Translate. How do I get back the address its
trying to jump to when it finishes the end of a basic block? If I enable
tracing I can see that it wants to jump or call a function at a address.
How do I get that address?

Stephen

On Fri, 2007-01-05 at 15:32 +0000, Julian Seward wrote:
> On Thursday 04 January 2007 21:29, Stephen Torri wrote:
> > Is the guest_bytes_addr variable marking the beginning of the memory
> > containing binary instructions in memory? That is similar to the image
> > base in Windows PE files?
> 
> Well, sort of.  Bear in mind vex just does the donkeywork of disassembling
> small fragments of code - extended basic blocks.  You have to tell it, via
> repeated calls to LibVEX_Translate, where those blocks are - it has no 
> understanding of executable file formats or any such.
> 
> That said,  UChar* guest_bytes  need to point at the address in the host's
> memory (ie, the machine running vex) where the instructions are.  Whereas
> Addr64 guest_bytes_addr  needs to say what (guest) program counter corresponds
> to that fragment of code.
> 
> > For example if a program loaded into memory has a image base of
> > 0x1000000 and a base of code 0x1000 so that our file loaded into memory
> > should begin at 0x1001000. Is the 0x1001000 what I put in the
> > guest_bytes_addr?
> 
> In that case you need to put 0x1001000 guest_bytes_addr and the actual address
> of where you have it in the host's memory into guest_bytes.
> 
> J