|
From: Eric E. <eri...@fr...> - 2004-09-01 01:03:40
|
Few ideas as they come, if they can help:
1. We can finely take control of all the memory space
by mapping everything available using MAP_NORESERVE.
If the client requires some space, we decide where we want
it to be mapped, unmap the reserved zone, and do the syscall.
The kernel won't have any other choice than mapping to the
zone we have freed, since it'll be the only zone available.
2. Run-time test is the only solution if we want to be sure
it works on all situations. Furthermore it is mandatory
for binary distributions. We have the means to do it,
with either the shmat trick or the previous reserving solution.
3. Not sure we can do that, but maybe PIE is not mandatory.
Can we have stage2 compiled only as PIC, mmap it where we
need, and perform the relocations ? I've tried a bit PIE,
and I feel it is not always working; testing for platforms
on which it works could become a nightmare.... But I'm not
an ld expert...
> P2. For kernels with "overcommit" mmapping off -- which prevents a
> process from allocating more address space than the available swap space
What are these kernels doing exactly ? Can't we reserve the space with
MAP_NORESERVE, and when we really need to use it, remap normally ?
If not possible, we can probably reserve the ranges using shm mappings.
> P5. Large executables (eg. 200MB+) cannot be loaded in memory by
> Valgrind in order to read their debug info.
>
> S5. Two possible fixes:
> - make client/shadow-mem/valgrind divisions less rigid
> - incremental debug info reading (but that's impossible for stabs)
Indeed there are other solutions. We are likely to always find
someone which will have an exe bigger than the space we have available...
Either:
- delegate dbginf reading to another process which has more free space;
communicate through ipc/whatever
- do not read the dbginfs. Have it done by another process
doing the post-processing (and filtering) of the vg results after
- recommend using dwarf2 instead of stabs, and make the reader incremental
- say concerned users to buy 64bit boxes (hummmm.....)
> The downside of switching to incremental shadow memory is that it makes
> direct-offset shadow addressing impossible, at least on 32-bit.
I wouldn't be so categoric. We can certainly do a big-bang _reservation_
(not allocation), using either MAP_NORESERVE or shm mappings, and
incrementally remap parts as we need them.
> Only question here is: where does the stack go? If the stack size is
> ulimited (eg. to 8MB), there's little problem. Otherwise, perhaps
> below client_mapbase, so it grows down towards the upward-growing
> heap. [nb: what happens if they collide? undefined?]
Wherever they are, if whatever collides, valgrind should issue
a precise error message, and provide a command-line argument so the
users can ask to reserve e.g. 256Mb of stack. I think it is safe
to have a default, relatively limited, maximum stack size, so
stack overflows could be detected quite quickly.
Cheers
--
Eric
|