|
From: Jeremy F. <je...@go...> - 2004-03-02 22:22:23
|
On Mon, 2004-03-01 at 17:15, Dirk Mueller wrote: > On Tuesday 02 March 2004 01:52, Jeremy Fitzhardinge wrote: > > > Yes. At the very least, stage1 needs to reserve the chunks of the > > address space needed for the client, before running the dynamic linker. > > Since the dynamic linker is unmodified glibc code, we can't control > > where it will place things, so we need to force its hand. > > Hmm, and why do we have to force it to place things in a certain way? Because the client address space is mapped 1:1 with the address space it would normally get without Valgrind (the difference is that it stops a bit short). FV creates a clear distinction between the client address space and Valgrind's address space, so that there's no scope for the client to start trashing Valgrind's memory. In order to achieve this, we need to make sure that all the pieces of Valgrind get placed outside the client address space (hence the need for the two-stage bootstrap). > > The other large mappings (like the shadow memory region) aren't really > > necessary, but they make inspecting things with /proc/<pid>/maps much > > easier. > > inspecting which kind of things ? Debugging Valgrind - for looking at the state of the address space as the program executes; in particular, you can see how shadow memory is being consumed. > > What's the purpose of your virtual limits. Is it to stop runaways, or > > actual malicious resource use? > > Well, both. it also helps debugging since you get a segfault instead of a > machine that swapped to death before you were able to attach a debugger. Well, in that case only setting the soft limit should be enough to prevent that failure. J |