|
From: Nicholas N. <nj...@ca...> - 2004-06-24 00:09:37
|
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?
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?)
- client-map-seg: (via VG_(mmap), native mmap())
- stack extension (on SIGSEGV)
- new thread stacks
- brk() allocations
- malloc() allocations, if malloc is replacement
- mmap() allocations [should include client libraries (?)]
- ipcop_shmat() allocations (?)
- [client stack]
- shadow memory (via shadow_alloc())
- V-map-seg: (via VG_(mmap))
- tmp .so debug symbols
- any libraries used by core/tools (?)
- 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]
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. A similar thing might be possible with the client
space. That's what I'm going to try next.
N
|