|
From: Eric L. <ew...@an...> - 2006-06-14 19:44:26
|
It turns out there was a problem in the module that parsed the binary into BB's. So I was finally able to get VEX to churn out the correct IR! Thank you guys for the help! Sorry about the vagueness of my question before. I have another question about PUT/GET in VEX. In the outdated documentation, it says PUT/GET is for moving values between CPU registers and Temp registers. In the VEX IR, PUT/GET uses offsets, which implies that it's addressed like memory, so then where do all the registers (eax, ebx, etc.) go? I looked at the IR for some common instructions and noticed that eax seems to be at PUT(0), is this always true? If so, is there a mapping of which registers go at which offsets somewhere? Thanks, Eric >>> 2. I'm passing BB's to LibVEX_Translate with the orig_addr argument >>> set to point to the first instruction in the BB > > You need to be clear about the meaning of "point to the first instruction > in the BB". (Didn't we discuss this before?) > > Vex is set up so that a bb to be translated is characterised by two > addresses: the address which they happen to reside in the host's memory > (VexTranslateArgs.guest_bytes) and the address which they are claimed to > come from in the guest (simulated) machine's memory > (VexTranslateArgs.guest_bytes_addr). > >>> but the translation that comes out does not match the translation from >>> just running valgrind --tool=none --trace-flags=10000000 >>> --trace-notbelow=0. And it's not a pre/post IR optimization issue >>> because I also compared against all the other --trace-flags. > > As Nick says, you need to send some examples of what you put in, what you > got out and how that differs from what you expected to see. Without that > it's more or less impossible for us to diagnose. > >>> Is there a particular format the BB's have to be in for VEX, e.g. have >>> some kinda header? > > No. > > J > > |