Re: Problem using .zerofill / -segaddr to create very large segments
Re: Problem using .zerofill / -segaddr to create very large segments
- Subject: Re: Problem using .zerofill / -segaddr to create very large segments
- From: Terry Lambert <email@hidden>
- Date: Tue, 22 Sep 2009 20:14:05 -0700
On Sep 22, 2009, at 5:10 PM, Jay Reynolds Freeman wrote:
My simple-minded view of the linker is that it is supposed to
reserve such segments as the user asks for, then arrange to put
text, data and heap in what is left over, and complain if for
some reason there is a conflict -- all this at link time.
It can't really do this _all_ at link-time, since it doesn't know the
size of the shared libraries you will actually run against, only the
ones you are currently linking against, and that can change in the
future. It can complain at runtime if you run your static segment
into the text of the program, the stack, or the heap, which may be the
issue, or you could be running up against a limit in dyld (which Brian
M.'s stuff might save you from, at least temporarily).
Similarly, I would hope for a useful run-time error message
if for some reason either the loader or Apple's own code cannot
make do with what the linker has done. What I actually get is
an error-free build and link, and then run-time messages about
not being able to load classes, with no hint of why, wherefore,
or who is to blame.
If you'd used the environment variables I pointed it, it probably
would have given you enough information to understand what's going on...
I believe I have a workaround -- Brian Mastenbrook posted code
for a program that writes the requisite .o file, though I have
not yet had time to try it.
You may or may not find yourself in the same boat; it depends on if
you are running yourself into the heap or the default stack location,
etc., which I really can't answer for you unless I was sitting in
front of your machine and did the things I've been telling you you
need to do to diagnose the issue.
Yet bugs in the linker, loader,
assembler, or run-time support stuff are worth chasing down;
unless someone turns up an obvious error in what I am doing I
will probably end up filing one or more bug reports on this
stuff.
I expect you'll get an assembler bug out of it, to get the assembler
to take 64 bit values, and you may or may not get a linker bug out of
it, depending on why it can't load the class, and whether you are
running into the stack, the text, or whatever with your huge segment.
By the way, the 64 bit process address space layout (as far as the
kernel is concerned) is documented in the published xnu sources, in
the file:
osfmk/mach/i386/vm_param.h
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden