|
From: Julian S. <js...@ac...> - 2012-03-02 10:42:22
|
On Saturday, February 25, 2012, Florian Krohm wrote: > On 02/23/2012 03:28 AM, Julian Seward wrote: > >> (1) Is the zero-out done on purpose? Perhaps according to the rationale: > >> by the time execution reaches those parts of the application > >> program a user cares about, glibc will have populated the registers > >> with some defined values anyhow? So why bother here? > > > > Well .. so the zero-out for the other architectures .. I did that because > > from a conservatism point of view. Getting an initial state that works > > reliably has been difficult (on ppc64-linux I had mucho trouble) so > > zeroing everything seemed simplest. > > > >> (2) If I wanted to initialize those shadow areas to mark the registers > >> > >> as uninitialized, what bit pattern should be stored? All bits 1? > > > > Yeah, 0 = defined, 1 = undefined. > > This is for vex_shadow1. > I think that vex_shadow2 should be initialized with all-zero. From what > I understand it holds otags and since no valid otag can be zero, zero > seems appropriate. Right? Yes. > Actually I think that the initialization of the shadow areas should be > done inside the tools. The tools determine ultimately what is stored in > those areas and what the encoded values mean. Yes -- you're exactly right. Zeroing it out is just .. simple. Besides, if any tool uses a shadow value before defining it then there's something funny with the program's startup code (or the the tool). But yes .. from a s/w engineering point of view it's actually more logical for the tools to initialise the shadow state. J |