|
From: Nicholas N. <nj...@cs...> - 2007-08-28 22:12:07
|
On Tue, 28 Aug 2007, Stephen McCamant wrote: > NJN> But one issue that worries me: even if the shadow size is only > NJN> double the normal size, will all the register stuff work in the > NJN> IR? For example, if the code is dealing with registers of type > NJN> F64 or V128, there's no way to talk about shadow registers of > NJN> twice that size, is there? It's probably ok for the integer > NJN> registers, but that's only part of the story. > > Yes, this gets to the point that what my tools are doing is in fact a > little more different. The notion of a multiplier isn't really the > most natural one for them, since it isn't that they want an n bits-1 > bit shadow area in the way Memcheck wants a 1 bit-1 bit one. Instead, > they want to have a fixed-size tag for each separate register (e.g., > 32 bits per register for the abstract type inference tool, at least on > 32 bit machines). So the most space efficient thing would actually be > to have a quite different guest-space layout, though depending on how > many registers of different sizes there are it might still have to be > bigger overall. But since the IR representation of guest state > locations is just integer offsets, this would require a somewhat ugly > lookup table. So every register has a 32-bit shadow, regardless of its size? In that case, specifying the absolute shadow guest state size might be better than specifying a multiplier. (And you don't have the problem I suggested because all your shadow values are normal Vex types. I guess if you wanted a shadow value that wasn't a Vex type (eg. 256 bits) you'd have to model it via a word-sized pointer to a 256-bit region. That 256-bit region could be in the shadow guest state or elsewhere. Hmm, I'm just thinking aloud.) What do you do about the overlapping registers, eg. eax/ax/ah/al? Nick |