|
From: Jeremy F. <je...@go...> - 2005-02-15 01:24:49
|
On Mon, 2005-02-14 at 18:43 -0600, Nicholas Nethercote wrote: > 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. I'm still concerned about fragmentation and intermingleing Valgrind allocations with client ones, though with a 64M chunk size it should be lessened. > It will be interesting to see how slow the check becomes, and how much it > bloats code sizes, though. Well, if we keep the address space as-is (though described in terms of superblocks) we can still use segmentation. > 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 That would become mandatory with the superblock scheme, since we could never rely on being able to mmap more than 64M. > - 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.) Have you prototyped this yet? It would be interesting to see how this works in practice, particularly handling pathalogical cases (since it would be pretty easy to write a program which has very atypical V-bit patterns, and it still needs to do something sensible). J |