|
From: Nicholas N. <nj...@ca...> - 2004-06-24 08:32:24
|
On Wed, 23 Jun 2004, Jeremy Fitzhardinge wrote: >> 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. Ok. So what should we do about it? We've survived ok so far without third-party libraries -- should we forget about using them and remove this code? To me, there's not much point in having broken not-used code in the repo, it's just confusing. >> - new thread stacks >> - brk() allocations > > No, these grow upwards from where brk() would normally allocate memory. Are you sure? The call stack for new thread stacks is: do__apply_in_new_thread() calls VG_(client_alloc)() which calls VG_(mmap)[CLIENT,FIXED] to allocate the memory The call stack for brk() allocations is: PRE(brk) calls do_brk() which calls VG_(mmap)[CLIENT,FIXED] to allocate the memory VG_(mmap)[CLIENT,FIXED] allocates in the client-seg-map area. >> - 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 the one given by the kernel, growing down from 0xbfffffff. >> 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. I don't see why V needs a heap at all -- is there any reason it can't do everything with non-contiguous mappings? That's how it was before the FV reorganisation. > 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... The question of how best to layout the address space is moot. But the potential reduction in complexity and code size will still be a boon. N |