|
From: Julian S. <js...@ac...> - 2005-02-24 11:16:27
|
[My ISP seems to have lost the last 24 hours of inbound mail. So am constructing a reply from the list archive at SF. Sigh.] Taking Jeremy and Greg's comments together, it certainly seems like flexibility over stage2 load addresses, overall layout, and perhaps superblock size is important. > >* The 64M superblocks have 4 possible ownership states: > > Unallocated > > Valgrind"s -- V"s text, stack, static data, dynamic data > > Shadow > > Client > > > > > Is there any difference between Shadow and Valgrind? Do they behave > differently in any respect, or is it just that their contents mean > different things? No real difference; they could be merged. I just thought it might be nice for debugging & accounting purposes to distinguish the two kinds. > > That"s not wonderful, but even a 1 Mb static area should hold > > enough info to track several thousand segments. > > > Well, you could still allocate them dynamically, so long as you do it > early enough (ie, before you"re so short of space that there"s no room > to describe the new space you"re allocating). Yes, that's the kludge we have at present. It's almost plausible, but I have been unable to figure out the boundary conditions that have to be observed to *guarantee* there will never be an infinite recursion. I don't much like the idea of a fixed-sized table either, but I have yet to be convinced the "early enough" scheme can be made reliable. > > - In general, on a 32-bit machine, because memory is allocated > > in 64M superblocks to either shadow, client or V-internal, we get > > rid of all problems associated with the current hard partitioning > > scheme between client and shadow memory. Big-bang allocation is > > done away with. We know we can still protect V from wild writes > > by the client at fairly minimal expense. > > > What problems are there, and how are they avoided by this scheme? * big-bang shadow allocation causes problems on kernels that don't do overcommitment * a fixed partitioning scheme is less appropriate if we move towards compressed representations of shadow memory, since that compression ratio could be variable > > - On a 64-bit machine, all code is to be mapped in below 1 G, but > > apart from that ASpaceMgr can be fairly relaxed about fragmentation > > in the area above 1 G. > > > Er, why? We have terabytes of address space to play with. Why make > holes in it? There"s no technical reason we need to put code down that low. Fair enough. I was just trying to come up with a single load address which would work OK for all Linuxes, but perhaps being flexible is better. See comment at top of this msg. > Also, choosing a fixed address prevents Valgrind from running under > itself. I think we should keep that. Agreed. I realised my initial proposal would have killed that and hadn't yet figured out how to fix it. > No, the main disadvantages are that this is fantastically complex, makes > us very dependent on the toolchain (particularly all the little > side-channels between gcc and binutils), and is architecture and OS > dependent (since not everyone uses ELF). By comparison, padding the > address space and using libc carefully are very simple and portable. > > I"m still in favour of 1) use PIE where available (otherwise choose a > static loading address), 2) using a flexible address space configuration > which allows Valgrind to run under itself, 3) try not to get too > involved with the object file formats. My current incarnation of the linker is 1400 lines of code, and that does x86 amd64 ppc32 sparc32 and arm (all ELF). Let me say I am less than convinced by this idea myself -- it's just a possibility. The dependence on object file formats bothers me, as does the lack of debug info support. It's just that I find the idea of address-space-padding kind-of unappealing, but otoh (1) it does appear to work, and (2) it's simple. So perhaps it's the least- worst option. I think what bothers me is -- on a 64-bit platform we will have to generate two temporary mappings that together cover almost all of the 2^64 bytes of address space. So are we assured that the kernel will not barf at this point? Particularly given that on RH8 we had kernels barfing on allocating a 1.5GB shadow area all in one go. IOW - padding is fine if it's reliable and portable(ish). So, exactly how reliable and portable is it? On non-Linux kernels? That I don't know. J |