site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com 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. 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. 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. 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. osfmk/mach/i386/vm_param.h -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Sep 22, 2009, at 5:10 PM, Jay Reynolds Freeman wrote: 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). If you'd used the environment variables I pointed it, it probably would have given you enough information to understand what's going on... 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. 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: This email sent to site_archiver@lists.apple.com