|
From: Greg P. <gp...@us...> - 2005-02-24 01:28:26
|
Julian Seward writes:
> 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.
25k should be plenty for ordinary apps; my web browser is currently
around 2k. I don't know what a database or sci/tech program might
look like, but in the worst case the answer is "recompile Valgrind"
which should be perfectly acceptable.
> > 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?
The primary issues are ones of specialized use of various parts of
the address space for 32-bit programs. 64-bit promises to be much
cleaner.
0x00000000..0x00001000: protected page zero (might be more than one page)
0x00001000..0xWhatever: typical executable; typically non-relocatable
0x8fe00000..0x90000000: dyld (dynamic linker); relocatable
0x90000000..0xb0000000: system libraries; non-relocatable in practice
0xbf800000..0xc0000000: default main stack; executable can specify
a different address or size; might be relocatable with some fancy footwork
0xfffec000..0xffffffff: libc special purpose; non-relocatable
No address space is reserved for the kernel proper. There's no
distinction between malloc-memory and mmap-memory; allocators
always use mmap-style heaps rather than sbrk.
The system libraries in 0x9..0xc are theoretically relocatable,
but in practice the kernel just slams them into their default
locations, ignoring anything else that's there. There's a bug
report filed against this, but it's unlikely to be fixed any
time soon.
Other special-use memory like thread stacks and window server
buffers have preferred locations, but will happily live
elsewhere as necessary. There might be additional special uses
in the last 32MB of address space (which has useful properties
in the PowerPC instruction set); it's easy enough just to give
that entire area over to the client just in case.
> > 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.
gdb can help, but it takes some extra work. Other tools can
be used to interrogate the location of loaded client libraries,
and then gdb's add-symbol-file command can insert the proper
knowledge into gdb's state. Clumsy, but not hopeless.
> What object file format does MacOSX use? ELF? How lucky are we?
Mach-O, which is entirely unlike ELF in many aspects that Valgrind
cares about. On the other hand, Valgrind's handling of stabs worked
almost as-is for debug info, at least at the level I've tried so far.
--
Greg Parker gp...@us...
|