Re: [Valgrind-developers] DynamoRIO

[Nicholas N. <nj...@ca...>]

On Tue, 19 Nov 2002, Julian Seward wrote:

> > Perhaps a slightly simpler approach would be to dedicate a register to
> > ESP rather than a memory location, so that it is persistently in
> > register across basic blocks.
> > [...]
> > Will still need to work out appropriate times to save ESP into the
> > baseblock for when control enters C code.

> Yes, this seems a good compromise.  We already played with the issue of
> 5 vs 6 allocatable registers and it makes very little difference at least
> to memcheck, so perhaps it would be ok to give one to %ESP.

I agree in principle.  One question -- how would this affect the UCode?
Would it look the same (eg. with all the %ESP PUTs and GETs) and then the
code generator would combine multiple UInstrs into single x86 instrs?  Or
would the UCode look different.  If the latter, how would this interact
with MemCheck's instrumentation?  It feels to me like this would be a good
thing to keep within the code generator if possible, so that %ESP is not
treated any differently from a UCode point-of-view, which makes life
easier for skins.

As for saving/restoring %ESP on C code entry/exit, that would make each
CCALL two instructions more expensive.  For skins doing lots of CCALLs
(eg.  cachegrind) that might be a loss -- the CCALL extra expense could
outweight the %ESP savings.  Not sure.  I suppose you could have a skin
"lots_of_CCALLs" `need' that switches between the two approaches, but that
would be a pain.

> > 2. Using trace caching will lengthen the effective size of a basic
> > block, and thereby amortize the register load/save over more
> > instructions

A related point:  I've noticed that for skins inserting CCALLs, often a
register is set and not touched for quite some time -- it's live range is
big.  If the register is a caller-save one (%e[acd]x) and one or more
CCALLs occur between the set and use points, it would be better to spill
it.

For example:

  set %eax
  ...
  code not using %eax, with multiple CCALLs
  ...
  use %eax

For each CCALL, %eax has to be saved/restored.  If there are 2 or more
CCALLs between %eax set and use, it would be better to set %eax and then
immediately spill it, and then unspill it immediately before use.

I'm not even sure if this happens a lot, but if it is maybe something
could be done in register allocation to avoid it.

----

> Nick, one thing you seemed to not comment on is ...
>
> >   addl $2, 36(%ebp)   (the INCEIP)
>
> ie, we keep exact track of %eip; does DynamoRIO ?  What sort of
> exception model at they presenting?

I'm not sure.  They have a "VPC" which I assume is a "virtual PC" in some
of their diagrams.  There's lots of detail in one of the papers about
handling unusual control flow in Windows (callbacks, asynchronous
procedure calls, exceptions, setjmp/longjmp) but I don't understand that
stuff much at all.  I'm not much use, sorry.

N