|
From: Nicholas N. <nj...@ca...> - 2002-11-21 15:43:27
|
Hi,
I started having a go at the INCEIP table lookup thing, but I got stuck...
On Thu, 21 Nov 2002, Julian Seward wrote:
> Difference here is we do table-based EIP reconstruction as needed
> and completely nuke INCEIP (yay!)
>
> So, precisely how to reconstruct %EIP from %eip? Like this. Firstly
> %EIP must be made up-to-date at the start of each bb, but it is anyway,
> so that's free. Now suppose we are in the middle of a bb and want to
> know the current %EIP. We actually know the block-start %EIP and the
> current %eip.
How do we know what the current %eip is?
Consider an example. When a 'value' error occurs in the middle of a
BB under MemCheck:
gen code calls the asm routine MC_(helper_value_check4_fail)
which calls the C function MC_(helperc_value_check4_fail)()
which calls MC_(record_value_error)()
which eventually calls VG_(maybe_record_error)()
which eventually calls VG_(construct_error)()
which (as tst==NULL) records VG_(baseBlock)[VGOFF_(m_eip)]
If we remove the INCEIPs, VG_(baseBlock)[VGOFF_(m_eip)] will be out of
date -- it will point to the start of the original BB rather than the
exact problem instruction.
So how do we find out %eip in order to look up the snazzy new eip-->EIP
table? Well, it's buried deep down in the stack as the return value
(minus one instruction) for MC_(helper_value_check4_fail). But that's not
a good way to find it out.
Alternatively, during translation, the original %eip is known for each
original instruction and so it could be passed as an arg to
MC_(helper_value_check4_fail). But that would bloat code for TESTV (would
need to push the arg and then clear it after the call) and it doesn't feel
nice. But maybe it has to be done this way?
Or am I missing something obvious here?
N
|