|
From: Jeremy F. <je...@go...> - 2004-06-24 01:31:05
|
On Thu, 2004-06-24 at 01:09 +0100, Nicholas Nethercote wrote: > Hi, > > I've done a big trawl through all the allocation functions. The good news > is that there's quite a bit of scope for simplifying them; various > functions have sprouted over time that do similar things to each other. > > First, a question: there's a file vg_glibc.c which defines overrides for > brk() and sbrk(). But, AFAICT, on my system they don't seem to be getting > executed, rather the brk() handling stuff in vg_syscalls.c is what gets > executed. Is this meant to be like this? Is vg_glibc.c necessary? That's some half-finished stuff I was working on. The intent was to intercept the low-level memory allocation functions so that we could use glibc mmap/malloc/new/etc from withing Valgrind without causing problems, so we can use third-party libraries. The trouble is that 1) there are some nasty cyclic dependencies which make startup hard, and 2) glibc makes it *very* difficult to intercept the low-level allocators consistently. The big risk is some code deep in a library running as part of the Valgrind context ends up using brk() or mmap() and allocating in the client address space, or worse, allocating memory without telling Valgrind's address space management code, and the mapping gets overwritten. So, I got stalled without really resolving these issues. > Second, AFAICT, this is how the main parts of the address space get used, > which is interesting reading: > > - client-heap: > - [client executable] > - nothing else (?) (no client heap as such due to brk() intercepts?) Yep. > - client-map-seg: (via VG_(mmap), native mmap()) > - stack extension (on SIGSEGV) Well, I guess, but that's really the client stack area, which grows into the map area. > - new thread stacks > - brk() allocations No, these grow upwards from where brk() would normally allocate memory. > - malloc() allocations, if malloc is replacement > - mmap() allocations [should include client libraries (?)] > - ipcop_shmat() allocations (?) Yep. > - [client stack] > > - shadow memory (via shadow_alloc()) > > - V-map-seg: (via VG_(mmap)) > - tmp .so debug symbols > - any libraries used by core/tools (?) Yes. > - V heap: (via VG_(brk) and VG_(get_memory_from_mmap)) > - [stage2 executable] > - proxyLWP pages > - parts of the TC and TT > - VG_(get_memory_from_mmap)() tool/core allocations (eg. in Massif) > - VG_(arena_malloc) non-CLIENT tool/core allocations > - VG_(malloc) tool allocations > - [V-stack] V's stack is the one originally given to us by the kernel, I think. Or do we still switch? > It's a tortuous call graph, but I think I've got it right. > > I think the V-map-seg and the V-heap can be merged -- Valgrind doesn't > need its own heap. We can certainly grow V's heap in the same area as mappings, but it might lead to more non-deterministic out-of-memory failures if they end up colliding. There's the other trick which Paul Mackerras (I think) suggested: putting the symtab reader into another process, and talk to it with pipes. Of course, all of this is moot in a 64-bit address space... J |