Re: [Valgrind-developers] Re: Another architectural thing ...

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

On Sun, 30 Mar 2003, Julian Seward wrote:

> any skin which wishes to track stack memory permissions must provide at
> least the general functions
>
>    new_mem_stack
>    die_mem_stack
>
> They may optionally provide any subset of the following:
>
>    {new,die}_mem_stack_{4,8,12,16,20,24,28,32}
>
> in which case those will get called in preference, in cases where the code
> generator can establish what the delta is, and generally when convenient for
> the code generator.  Code generator will try to call the specialised fns but
> does not promise to do so, if it isn't convenient for it.
>
> The specialised functions are passed %ESP after the adjustment has been made,
> ie the new value.  The general fns are passed old and new values.  None of the
> functions can make any assumptions about alignment; they have to check for
> themselves.

Yes.  Or maybe the specialised functions can be passed the old %ESP, that
might make slightly more sense for them.

Something else occurred to me though.  This "trackable event" is something
that the skin could do -- it could spot PUT %ESP instructions itself --
it's currently done by the core just as a convenience for skins.

So my second idea is this: make the skins do this.  Don't have any core
"trackable events" for this (new_mem_stack, etc).  Instead, have the core
provide a function VG_(ESP_changed_by)().  When a skin instruments a PUT
instruction, it can call this to see what the ESP delta is.  Some special
value (0? 0xcfffffff? 0x87654321?) would indicate "don't know".  The skin
can then choose to CCALL whatever function it likes based on this value,
eg. a specialised one if it was a common delta, or a general one if an
uncommon or unknown delta.

It would have exactly the same effect as doing it with "trackable events",
but gives slightly more flexibility to the skin -- it could have as many
specialised %esp-adjustment functions as it wanted, which could have any
function arguments it wanted -- and would not saddle the core with this
family of "trackable events".  But it wouldn't make life any more
difficult for the skin... well the only onus is on the skin writer to
realise they have to use this function if they want to know about
%esp-adjustments.  But skin writers have to know about a lot already, so I
don't think this is so bad.

Combining this idea with the move-malloc-into-skins idea, and we've lost
quite a few "trackable events" -- new_mem_heap, new_mem_stack, etc.  This
represents a minor shift in philosophy.  Previously, "trackable events"
were for things that couldn't be detected by the skin, plus enough other
events to cover all memory operations of interest.  With these proposed
changes, "trackable events" would only cover those things that couldn't be
detected by the skin.

In one way this is bad -- there's no uniform mechanism for detecting all
interesting memory ops.  But in another way it's good -- the core is purer
(more RISC-like, if that sounds better :) since "trackable" events really
are only those things that cannot be detected by a skin.

To me, this feels like the right way to do things.

> As a sanity check, let me ask (possibly again): does this scheme in any way
> mess up the nice core/skin split, or generally clog up your architectural
> cleanups in any other way?

No.  And with my new proposed change, it's even better :)

N