🚀 go-pugleaf

>>     I was handed a source tree, the most horrid makefile I have ever seen
>> and was told to get the code to compile and run with CW Pro 7 (its a
>> mach-O
>> app originally compiled with gcc).  I have got it all compiled and it
>> actually runs, but I am hitting a snag.  Apparently the code assumes that
>> other memory has been prebound by the linker (LD command in the makefile)
>> to specific memory addresses.  I know which how much memory needs to be
>> prebound, but I just don't know how to prebind it...  I'm also not that
>> familiar with prebinding in general...
>> 
>> How do I prebind some memory into specific memory space in CW 7?  Is
>> there a postlinker I can use?  Prelinker?  Do I have to write some
>> custom plug-in to do this (hope not)?
>> 
>> I can't change the code btw (if I can help it), only my CW project cause
>> they still want this thing to compile in gcc and run.
>> 
>> Thanks for any help...
> 
> Traditionally Macs have used position independent code, that is loaded
> by the loader at whatever address the loader feels like. There is no way
> to control what address your program is loaded at. However, one of the
> system calls in Mac OS X is "mmap". Open a Terminal window and type:
> 
> man mmap
> 
> as you'll see, it takes a piece of the virtual memory address space and
> maps it to a specific disk file. I've used this in the past to implement
> a malloc arena so that I could get multiple threads on multiple CPUs to
> all see the same graph data structure, and have the data-graph be
> persistent: days later, a thread could mmap() the universe file, and
> start right up. No need to read the entire data structure from a file
> and rebuild the spider-web of pointers: one mmap(), and the VM system
> does my file i/o for me, with no i/o routines to debug.

Thanks for the reply.  The traditional macOS would not support what I am
trying to do.  This I know.  OS X, on the other hand, does support this.  It
inherits it from NeXT.

I don't think mmap is going to be a good long term solution to this problem.
The memory I am mapping has the potential to be huge, and I don't think
anyone is going to like have some huge file laying around when they run my
app.  Plus the disk access time would seriously slow things down...

I know this can be done.  gcc does it perfectly with -segaddr, -ld linker
commands (they are described in the man pages), so I assumed Codewarrior
would have a similar functionality.

Basically what this is supposed to end up doing is, when my app gets loaded
into RAM, the loader will get commands to pre-define chunks of memory in my
apps memory space in locations that I choose.  So when my app runs it has it
hard coded that this memory is there and that it can access it etc.  Its
hard for me to completely explain it without giving out some proprietary
info, but it has to be done this way.

I'm sorry to say that if I can't find a solution to this problem, then this
project will get scrapped and my group will have to continue to use gcc, gdb
and MPW....  That would suck...  I can't stand gdb or MPW...  That�s why I
started this project to get things running on CodeWarrior...

Thanks again...

--Rob