Path: utzoo!censor!geac!torsqnt!jarvis.csri.toronto.edu!rutgers!mailrus!ames!amdahl!ntmtv!hopper
From: hopper@ntmtv.UUCP (Ian Hopper)
Newsgroups: comp.realtime
Subject: Re: Memory management under VxWorks
Message-ID: <865@ntmtv.UUCP>
Date: 3 Mar 90 05:16:58 GMT
References: <8136@pt.cs.cmu.edu>
Organization: Northern Telecom, Mtn. View, CA
Lines: 37

From article <8136@pt.cs.cmu.edu>, by hmp@cive.ri.cmu.edu (Henning Pangels):
> 
> no way to have system calls allocate memory out of anything but the system
> pool.
> 

I think a simple solution might go as follows:

VxWorks is a library-based OS.  You generally statically link your application
with the OS into a single executable file/PROM/ROM/Whatever.

Now you look at the Unix linker that you are probably cross-compiliing with.
When a reference to malloc occurs within "VxWorks.a", if a malloc (that you
have written and placed earlier in the linker command line) exists then the
malloc from VxWorks.a gets ignored, and yours get used.

So perhaps:

ld -"crypic" yourApplication.o yourMalloc.o VxWorks.a

might result in the VxWorks OS using your version of malloc.

However, you must now implement malloc *from scratch*.

yourMalloc.c:

char FreeSpace[LARGE_NUMEBER];

char *FreePtr = &FreeSpace;

... and so on ...

Let the net know how things go.

-- 
Ian Hopper		{amdahl.com,ames.arpa,hplabs}!ntmtv!hopper
Northern Telecom Inc.	[Clever comment under construction.]