|
From: Eric E. <eri...@fr...> - 2004-09-02 19:31:36
|
Nicholas Nethercote wrote:
>
> Shadow addressing is done with a two-level table. [...]
>
> So even though we have the conditions now for direct-offset shadow
> addressing (ie. we have a big contiguous block of shadow memory) we do
> *not* do direct-offset shadow addressing.
Well, I assumed that the big-bang alloc was made for the purpose
of direct offset shadow adressing, and so that it was done...
The question is then: What, at that time, decided you
to do the big-bang mmap ? I feel we may fall in a classic
software engineering syndrom, where you do one thing, change it
to another because it does not work well, change back to the first
because it is not better, then back to the second because you are
not satisfied, etc.
I have had a look at the ML archives, but couldn't find any
explication other than for direct offset shadow, and need for
a barrier between client and vg. But the reasons are not clear.
Any other hints on that ?
> Look at get_abit() and set_abit() in addrcheck/ac_main.c for examples.
Indeed, I had a look a few months ago, but did not remember the
particular details. It just means that we won't reduce performance
by... keeping the current implementation :-)
>>> Exactly, that's why I'm arguing against direct-offset shadow addressing.
Agreed, it's only trouble. The 32bit address space is too limited
to waste it. And the performance is correct with current scheme.
> Debug info reading is not the only problem. I listed 5 problems in my
> first email, debug info reading is only relevant to P5.
> this can easily exceed 256MB. This is the difference between P4 and P5
> in my first email. Go back and read them again.
Don't worry, I had them well in mind and in front of my eyes ;-)
I just need a few more tokens on P4, because we already
had possible supposedly working solutions for:
- P1: PIE + layout detection
- P2: PROT_NONE + MAP_NORESERVE and/or shm reservation
- P3: layout detection + (big bang or incremental shadow alloc)
Summarizing P4 and P5 gives the following constraints:
For P4, tools need to have a heap. They don't care where the big
areas are allocated, neither how they get chunked in small
blocks by VG_(malloc). Arenas improve perf, and that's good.
Flexible barrier (or no barrier) (would) help sharing the address
space between the tools and the client, because some times
the client requires a lot of mem, and some times the tools do.
P5: At any moment, we may need to have, say 500Mb of consecutive
address space available to map a big file. This is very temporary,
and while we have this mapping:
- The client does not execute
- We increase VG heap usage with the dbg infos we are parsing.
With the client needs being the following:
C1. text, data, bss fixed size segments
C2. a (down-growing) stack. May need to be very big in some cases
C3. an (up-growing) heap (brk) region. May need to be very big in some cases
C4. additional addressing space for file/anonymous mappings
(malloc will fallback to that if brk() fails
C5. reserved fixed address space ranges (very rarely)
And VG + tools needs being:
V1. text, data, bss - don't care where they are
V2. a small stack - idem
V3. chunks for shadow memory - not contiguous, don't care where they are
V4. mapping ranges for VG_(malloc) - no need to be contiguous
V5. Temporary BIG area for file mappings (for now)
I found a solution for P1..P5 which seems credible.
Based on the assumption that we don't need to have
a barrier (even flexible - BTW, what did you
mean by flexible ? command-line arg, or adjusting during
the execution ?), we can have C4, V3 and V4 interleaved,
and V5 taking the maximum space available after C3 and/or before
C2 since C2 and C3 won't grow while V5 (file mapping) is needed.
C2 (stack) should have a reasonable default, but be parametered
through a cmd-line arg (e.g. --min-stack-size) for
specific purposes.
Idem for C3 (brk). Note that having a limited heap region
should't bother too much apps, if their malloc uses
mmap() when brk() fails.
Optionally we could add --max-XXX-size if people want
to test under memory constraint.
So the following layout could work:
0 ===========================
Shared area 1 (DOWN)
...
VV--------------VV
available to vg & client
cli_data ===========================
client heap (DOWN)
...
cli_data_end VV----------------VV
[Temp vg mappings]
^^----------------^^
....
Shared area 2 (UP)
cli_stk_max ============================
Unused / Unusable
cli_stk_cur ^^----------------^^
.....
client stack, (UP)
space_end ============================
Kernel space
0xFFFFFFFF ============================
=== for limits fixed at once
--- for limits moving during the run
Shared areas (SAs) can contain C1, C4, V1, V3, V4
blocks.
Of course this is just an example, we may decide
to setup things differently, e.g.
- I didn't put the VG stack anywhere; could take
8 Mb in SA1, or be put at SA1 end, etc.
- Client stack is constrained, could be moved at
end of SA1 (needs arbitration between allocations
in SA1 and SA2 : less max client stack or less
maximum file mapping and less max client data.)
- There could be less or more shared areas
- Zones can be ordered in other manner
The important points in this idea are:
- No more address address space separation between
Valgrind and client
- At startup, depending on the view we have
of the address space (scanned), command-line
options, whatever, we decide a layout
and fix (compute) the hard limits.
- The big file mapping areas is between the client heap
and a shared area which is used in last resort.
- At runtime, we arbitrate the allocations in the shared
areas. For previous model, we would first try
to use everything in SA1 before using SA2 because
it impacts client heap and max mappable file size.
- If something goes wrong, we issue a clear message
telling the user to increase e.g. the min avail stack
size or min avail heap size on the command-line
I re-read carefully P1 through P5 and found nothing
problematic remaining. The only question I have no answer
is why was there a barrier between vg and client. I feel
it is not needed.
> [Modularization, Unit testing, ...]
> This will require some work to improve the modularisation a bit (ie.
> decreasing coupling and making modules as self-contained as possible)
> but that's a good thing.
Clearly a big task which could really improve the quality...
Volunteers ? ;-)
> But self-hosting would definitely be a good thing too.
With the shared areas, it shouldn't be too difficult
to have the 3 pseudo-processes (VG1 + VG2 + Client)
sharing the same address space. Probably with a bit of
cooperation between VG1 and VG2...
--
Eric
|