|
From: Nicholas N. <nj...@cs...> - 2005-02-15 00:43:49
|
On Mon, 14 Feb 2005, Jeremy Fitzhardinge wrote: >> So, what am I missing? > > It looks reasonable. For ia32 I would suggest sticking to the current > layout, so there would just be a series of fixed, preallocated > superblocks. In fact, for any 32-bit implementation I think that's the > best way to go. Since there are only 64 superblocks, we can pretty > easily determine in advance whether they'll end up being client or > Valgrind usable (maybe a few of them would be unallocated). It sounds pretty good to me too -- keeps the nice property that the client cannot trash V, but also allows more flexibility in layout. I would suggest that on 32-bit platforms we don't keep things exactly as they are now; I think the shadow memory should be allocated on demand, rather than in a huge chunk at the start, which is the main cause of address layout brittleness. It will be interesting to see how slow the check becomes, and how much it bloats code sizes, though. There are two other ways we can reduce address layout brittleness: - read debug info incrementally, so as to handle huge (300MB+) executables and shared objects - move to a compressed V bit scheme for Memcheck, which can reduce shadow memory requirements from 9 bits-per-byte to 4 bits-per-byte. (This is feasible because the vast majority of V-bytes are fully defined or fully undefined.) > For 64-bit, there's no reason we couldn't use, say, a 16Gbyte super-page > size and have a 16k-entry table for a 48-bit address space. At the > moment Linux constrains user-space to 256Gbytes, but after 2.6.1[12] > that will unconstrained (ie, up to 2^47 or so, I think) because it will > use a 4-level pagetable structure. At that point, we could put Valgrind > way up high and leave the client with a very clear address space. Sounds ok too. N |