in general, you are correct.
But the situation I have is quite different.
Originally the code is running on arm system, and the debugging
environment of arm provides it's clib, not open source, to help on
malloc, free , printf and scanf, etc. without OS support.
Uh, no.
The debugging environment provided you with a (however minimal) operating
system.
That's the key here -- the code which drives the hardware IS the OS, even
if it's a really lame OS.
Now I have to cross compile it on the sparc system, which don't have
such clib.
Uh.
You have code which runs on a given machine at a low enough level that
it's reasonable to think it would run without an OS.
You want to run it on another machine.
Why on earth do you think you can do this?
Does this program DO anything? Does it, at any time, accept some form of
input? Does it produce some form of output?
If so, either there is an operating system, or this program is doing so
through hard-coded direct access to the hardware.
If the former, well, there's your answer -- get a corresponding OS on the
sparc machine. If the latter, you're going to have to completely rewrite
all the code that does that input and output, in all probability.
I try to remove malloc but it is to much that make it impossible.
I have write my own printf and scanf.
But malloc seems quite complex, it seems have to implement a heap and
manage which slot has been allocated and released.
I just try to find a func which is initialized by telling it the
starting address and size of free memory.
Then malloc it.
There are functions similar to this in most C libraries, several of
which are available as free software under various licensing terms.
I'm pretty sure the BSD malloc/free could be tweaked relatively cheaply
to use a static block of available memory instead of system calls.
But think ahead a little further. Think about the I/O. If you can't
do the malloc part, I don't think you have good chances of dealing with
the problems you run into at execution time.
This is a really good time to start from scratch and, for instance, make
sure you understand all the critical code paths. How does input get accepted?
How similar is the corresponding hardware on the new box?
For that matter, how sure are you that you even have appropriate permission
to be doing this to this hunk of code? This sounds like the sort of thing
that might be part of a vendor SDK, and it may have licensing terms that
don't allow what you're doing.
-s