|
From: Julian S. <js...@ac...> - 2005-02-23 23:04:40
|
Greg
> Note that "complete control" cannot be totally complete in a
> Mach environment.
> [...]
> When Valgrind goes to allocate new non-client memory, it would
> first uses vm_allocate to claim an entire superblock-size region,
> and only then carve up the space inside.
This is useful stuff. Thanks.
What I plan to do is build an abstraction layer for messing with
the underlying OS -- sort-of an enhanced and cleaned up vg_mylibc.c,
so that V proper is insulated as much as possible from these
kinds of details. It's long overdue. With a bit of care it sounds
like it's possible to design the boundary so that MacOSX can be
plugged in underneath it too.
> > That's not wonderful, but even a 1 Mb static area should hold
> > enough info to track several thousand segments.
>
> How many thousand? Big Mac OS X apps already routinely use a few
> thousand VM blocks in client space, though this would probably be
> smaller after Valgrind's coalescing.
Well, let's say a block descriptor involves { a start address,
a length, a word containing flags, an int index into a filename
table, and perhaps a couple more words to make administration
a bit faster }. That's 40ish bytes. That gives 25k descriptors
per megabyte. How many do you need? Even if you need 200k
descriptors I don't care if we have to statically allocate 8M
to make that work. The only real issue is ensuring that update/
query operations on the map don't get too slow due to a compact
representation.
> > * At least for Linux, stage2 is loaded into a 64M superblock
> > just below 0x4000'0000 (1 G). ASpaceMgr allocates superblocks
> > on demand, above 1G if it can for shadow memory and for Valgrind's
> > own use, and below 1G for the client, if possible. In particular
> > it tries hard not to put Valgrind or Shadow data in the area
> > below 1G.
>
> This is all flexible, right?
Yes, definitely. I'm aiming for something which (1) is flexible
and (2) clearly separates policy from implementation.
> Mac OS X has some entertaining address space requirements and
> restrictions.
Can you summarise what they are, so I can muse on the consequences
thereof?
> > - On a 64-bit machine, all code is to be mapped in below 1 G, but
> > apart from that ASpaceMgr can be fairly relaxed about fragmentation
> > in the area above 1 G.
>
> Where does the "all code below 1G" requirement come from? Is that
> particular to the codegen in 64-bit Linux? Does Valgrind need it
> for some reason? Is it just a preference?
This is an amd64-linux issue. It seems that at least some
AMD64 distros (SuSE) are built using a "small model" where
offsets in literal jumps are signed 32-bits and so that appears
to force all code below 2 G. Or at least into some contiguous
2 G range.
I must admit I don't exactly understand the issues for layout and
code models on amd64. Can any amd64-linux junkies clarify this?
DirkM?
> > (3) Use a standalone ELF .o loader/linker to load all the .o's,
> > link and start them.
> >
> > At first (3) sounds insane, but it has a couple of advantages:
>
> It's not that insane. I wrote a system that does something
> similar for Palm OS, to get around its restrictions on code
> size and global variables. A full-blown ELF .o linker was
> overkill for me;
Well, the work is already done - here's one I made earlier:
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/rts/Linker.c
It works for ELF on x86, amd64, ppc32, used to work for arm,
looks like it can be made to work for ia64, and (at least at
some point in the past) could also load/link Windows PEi386
object files :-) It's a modular linker and so can be extended
to new formats (eg COFF) by writing the appropriate COFF-parsers.
> My Mac OS X launcher has this problem. gdb can see Valgrind's
> symbols, but can't set any breakpoints, and is easily confused
> about other things. gdb knows nothing about the client or its
> libraries. It's all rather clumsy to work with, but not the
> end of the world.
Not good tho; if V crashes we really want GDB to be able to say
what's going on.
What object file format does MacOSX use? ELF? How lucky are we?
J
|