Re: Problem using .zerofill / -segaddr to create very large segments
site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com
Have you tried using the "vmmap" tool to investigate the virtual memory map of the process that you're having trouble with? That should enable you to investigate where the free regions of VM are likely to be at the correct point in your program's execution. I had previously used a run-time mechanism for figuring out what absolute address to use for the shared memory. I would like to get away from that because it is difficult, confusing, and error-prone to try to have multiple processes coordinate on this matter: If for any reason Apple's frameworks or system software are allocating in a different pattern for the different instances of the programs that need to share memory, finding a place to put the shared block is a mess. There certainly are ways to reserve memory at link time at specific addresses; assembly-language programmers have been doing that for decades. I just want to use the same techniques in my applications. That approach is straightforward and should be robust. 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. -- Jay Reynolds Freeman
Jay_Reynolds_Freeman@mac.com http://web.mac.com/jay_reynolds_freeman (personal web site) _______________________________________________ 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... This email sent to site_archiver@lists.apple.com
participants (1)
-
Jay Reynolds Freeman