|
From: Florian K. <br...@ac...> - 2012-02-19 17:11:03
|
On 02/19/2012 06:10 AM, Julian Seward wrote: > > The translation will have > PUT(offs-PC) = some-address-in-vgpreload_memcheck-amd64-linux.so:malloc > for its PC update IR fragments. But remember, the program actually > called libc.so:malloc, and so the value stored in > guest_state->PC at that point (when the translation is made) is > the entry point for libc.so:malloc. > > For this all to make sense, the translation table (managed by > m_transtab) contains a binding > (&libc.so:malloc -> this translation), so that subsequent calls > by the program to libc.so:malloc lead back to this translation. > > This, I suspect, has much to do with what you observe. Fun, > isn't it :-) > Yep, this explains pretty much what I see. Thanks for taking the time. > One way to mostly get what you want is to suppress your optimisation > just for the first PUT(IP) = ... in the block (iow, make sure the > first is always an 8 byte PUT). After that you should be safe. I don't > know if you can do this without changing the the generic interface > used by guest_bb_to_IR.c to call the guest-specific insn disassemblers. > Exactly, that is what I had coded up. > Another way to get what you want is to put the cleverness in the back > end instead. In the insn selector, keep track (perhaps in the ISelEnv) > of which virtual regs have known constants. Then, when you see > "PUT(...) = 64-bit constant", see if you can do it with > > rTemp = (selected vreg) + small constant > *(rBaseblock + offs_IP) = rTemp I had something similar in mind, namely to track the contents of certain guest state entries: IA and condition code thunk. The rationale is that newer s390's have an insn to add an 8-bit immediate to a storage location. So an update of the guest_IA is a single insn in most cases. No register being used. Binding the guest_IA to a temp creates a loooong lifetime which the register allocator will not like... Florian |