|
From: Nicholas N. <nj...@ca...> - 2004-09-02 10:50:38
|
On Thu, 2 Sep 2004, Julian Seward wrote: > One point to bear in mind is that the conversation that followed > appeared to be silently predicated on the assumption that Linux is > the only kernel we're interested in. Some of the stuff (using mmap()) is plain POSIX. But the stuff about overcommitting, etc, is Linux-specific. In general, I'm not happy about relying on doing huge (eg. 1.5GB) mmaps. Seems too fragile in general. > We have to think beyond that: I would love to make V available for > MacOSX, and I bet (eg) the OpenBSD folks would love to get their hands > on an x86-openbsd variant of Valgrind. Indeed, once Nick's current > commit set goes in, one interesting experiment would be to try an > openbsd port. Or freebsd (already exists) or netbsd. Definitely. Once I've finished putting the structure in place, it would be great if someone (Doug?) could create a patch for FreeBSD, like Paul has been doing for PPC. Hopefully the changes required won't be too big -- just some factoring -- in which case I don't see why it couldn't go into CVS if it's working reliably. In contrast, PPC will require UCode reworking, so that's not going to be able to go in quite yet. > Let's just forget about big-bang shadow allocation. It causes a whole > bunch of problems, we're not using it at the moment, No -- we are using it at the moment. However, we are not using direct-offset shadow addressing (for which big-bang shadow allocation is a prerequisite). Sorry if I didn't make this clear, seems like I should have been more careful with my terminology in the RFC. > and we don't have > a clear picture of where the cycle-level costs of shadow memory come > from anyway. For example, if shadow memory really kills us because > it jacks up the D1/L2 cache miss rates, then it's going to do so > regardless of the address translation scheme in use. Yes. >> 4. Maybe make the --pointer-check=no change, if it seems useful. > > Well, I like the fact that currently the client can't trash V. Yes, the default would be --pointer-check=yes, which maintains that non-trashing property. The mooted change would only take effect if you specify --pointer-check=no; that would only be used for really difficult cases where we really can't get it to work otherwise. > Another thing to consider is how to achieve this portably, on non-x86s. > If the client address space is contained entirely in 0 .. N-1, and N is > a power of two, ANDing is obviously a cheap solution. Actually, we just need one of the following to be true: the client must be within 0..2^N or Valgrind must be outside 0..2^N Ie. there could be unused address space between them, and the dividing line just has to fall within that. But this seems problematic -- the only dividing line that really makes sense for 32-bit is either 1GB or 2GB, which doesn't allow the client to get very big. > If the machine contains a scalar 'min' insn, then we can do this cheaply > for any N. Yes. Is such an instruction common? N |