|
From: Jeremy F. <je...@go...> - 2004-09-08 21:01:14
|
On Wed, 2004-09-01 at 22:48 +0100, Nicholas Nethercote wrote: > >> Not sure it's worth doing it for now. How many people still use > >> stabs (on the platform we support...) ? > > > > Valgrind's dwarf support is pretty weak compared to the stabs support - > > there's nothing there to extract type information. > > But Helgrind is the only tool that uses the type information, and not many > people use Helgrind. Well, any tool which wants to describe an address symbolically could use that stuff. Its just that the other tools haven't been modified to do so. Actually, I thought memcheck/addrcheck do use it, but since they're mainly talking about values, it doesn't come up terribly often. > > We only need to resort to padding things out either before we gain full > > control (constraining ld.so to put things in the right place) > > I'm surprised that people with non-overcommitting kernels are not having a > problem with this step, but are having a problem with the big-bang shadow > memory allocation. I would have thought the padding done by stage1 would > involve more than 1.5GB worth of maps. They're mapped out of a file (mainly so we can identify them again later, but it has the nice effect of not triggering the overcommit logic). > >> BTW, now we are speaking of mem layout, I think it is very important > >> to keep in mind that it would be great to bootstrap V... > > > > You mean self-virtualization? That's a goal, but its tricky. > > PIE should help, though. That solves one problem, but Valgrind is its own worst enemy in this respect (it does a pile of things we'd hope to never see in a client). J |