|
From: Nicholas N. <nj...@ca...> - 2002-11-22 12:03:05
|
On Fri, 22 Nov 2002, Julian Seward wrote:
> Second part of the trick is that we can probably constrain ourselves to
> scanning about a dozen or so stack locations; the RA must be in that area.
> Consider what the stack looks like immediately after the doing the call
> insn which leads to the helper (stack grows down):
>
> RA for VG_(run_innerloop)
> saved ebx, ecx, edx, esi, edi, ebp pushed at start of VG_(run_innerloop)
> RA for where VG_(run_innerloop) calls translation
> /* stuff below is created by translation and helpers it calls */
> RA for call to helper ("MEMEME") (since all args are passed in regs)
> /* stuff pushed by stack of helper functions */
> /* top-of-stack; %esp points here (or one word above) */
>
> Imagine now we grab the value of %esp at entry to VG_(run_innerloop) and
> park it in some global variable. If my picture of the stack is right, we
> can find the relevant RA ("MEMEME") by scanning downwards from that value
> for 8 or 9 words, looking for a word satisfying the constraints mentioned
> above. If we have to go even a few words further, we've probably missed it.
>
> The combination of value constraint and location constraint should make
> this fairly good at finding the correct RA. The main danger AFAICS is
> that the 6 regs saved at the start of VG_(run_innerloop) might hold
> an spuriously matching value. Even that can be avoided by snapshotting
> %eip after those are pushed, in which case we're even more strongly
> location-constrained: there can be only about 3 or 4 words to search
> before declaring that we've missed it somehow.
Do you mean "%esp after those are pushed"?
Actually, won't we know exactly which stack location it should be in, ie.
immediately after the RA of VG_(run_innerloop)? Or can extra stuff get
put between the two RAs?
> How does that sound? Does it make sense? Is it utterly horrible?
> I'm not sure if something this fragile is really a good idea, but still
> it might be worth trying ...
Another thing is that we have to subtract 6 (or whatever) from the RA to
get the right %eip before doing the eip-to-EIP lookup, but that's fine.
I'm starting to come around to this idea now...
N
|