|
From: Nicholas N. <nj...@ca...> - 2004-06-29 15:07:13
|
On Tue, 29 Jun 2004, Nicholas Nethercote wrote: > You're right about the heap; I stumbled across the startup delicacy > involving it pretty quickly. Without it, there's a real bootstrapping > problem, in that V needs the segment list initialised before it can allocate > any memory for itself, but it also needs to allocate memory in order to > initialise the segment list. That's why I've done this partial overhaul > rather than the full thing, because I can't see how it can be done easily. I've worked out how to do this now. The solution is only mildly hacky -- the first superblock allocated by newSuperblock() is now done not with a mapping, but with a static block. This gives the startup code enough memory to play with in order to set up the segment list, and safely start allocating with VG_(mmap). I've got checking in place to ensure that this all works as it should (eg. that the static block is big enough, and that the segment-list-initialisation code is responsible for the first allocations). Using this, I've been able to remove VG_(brk) and Valgrind's heap, and am doing all V's allocations in its map-seg-area. So far, so good. Currently V itself (stage2) is always mapped at 0xb8000000 which is sucky (this is the 'kickstart_base' value). In my new version I'm putting it at 0xbf000000, just below V's stack (libs get put lower now). But the number is still hardwired, and based around the assumption that the stack starts at 0xc0000000. I thought an install-time test that determined where the stack normally goes could be useful for systems that put the stack at eg. 0xffff0000 -- I could put stage2 a short distance before the stack, and everything is done relative to that. Another problem is the libs used by Valgrind (ld.so, libc.so, libdl.so) which get loaded before main() begins. Basically, I'd like to jam them up just below stage2, but this requires knowing how big they are, and I can't see how to do that. Any ideas? Thanks. N |