|
From: Julian S. <js...@ac...> - 2006-06-06 22:34:40
|
> It seems like the 6th and 7th arguments to LibVEX_Translate, Don't use the 3.1.1 vex; use the one in the 3.2.0 release candidate (http://www.valgrind.org/downloads/valgrind-3.2.0rc1.tar.bz2). All these zillions of parameters got put in a struct, which is a lot cleaner. guest_bytes point at the actual insn bytes to read. guest_bytes_addr, as you say, is where we claim those bytes are in the guest process address space. You can put what you like there; I guess it depends on whether or not you care about the address relationship between different basic blocks or not. guest_bytes_addr_noredir, or whatever, is gone. All that ugly redirection crap is handled entirely on the valgrind side now. You have two main problems. One is you need to make vex not chase over bb boundaries. You can do this by using a VexControl struct with guest_chase_thresh set to zero (you have to supply this struct at some point, I can't remember where). If you do that then if you're lucky vex will not try and disassemble beyond the blocks of code you give it. But that's fragile since it relies on vex's decision about the end of a bb matching that from your own disassembler. I guess one kludge is: if you want to vexify a block which you know contains N instructions, you can initialise vex and set VexControl.guest_max_insns to N (along with setting .guest_chase_thresh to zero). Then it should stop after N insns even if it thinks it could go further. Does that make any sense at all? J |