[coldfire-gnu-discuss] Making malloc threadsafe
Nathan Sidwell
nathan at codesourcery.com
Mon Mar 12 08:44:04 UTC 2007
Daniel,
newlib's malloc cannot be made thread-safe without writing OS specific code.
Namely some kind of semaphore in the malloc_lock/malloc_unlock functions that
you found. You need to replace those. Simply wrapping all your own calls in
equivalent code is insufficient, as newlib uses malloc internally.
> It seems I may have partially solved this problem myself. If I don't
> replace malloc_lock/unlock in one of my own utility libraries that I
> link in, but instead implement them in the main.c file it seems to stop
> the linker saying that they have been redefined..
Right, this is probably a consequence of the usual linker rules in resolving
missing symbols (you don't give a command line, so I cannot be sure). Namely,
all explicitly specified object files are pulled in, then the libraries are
searched for remaining missing symbols. Each library is repeatedly scanned in
turn until no new objects from it are pulled in. Then the linker moves on to
the next library. Libraries can be grouped so they are repeatedly scanned as a
group, rather than individually. I'll have to check newlib to see whether the
dummy lock/unlock functions are in the same object file as something else that
is being pulled in.
> Is there a better way of doing this however (a function attribute or
> linker option) that tells the compiler or linker that I want to use my
> version (implemented in a library or otherwise) of these functions?
hmm, making the dummy malloc_lock malloc_unlock functions in newlib weak would
probably be sufficient. I'll add that to the feature wish list.
nathan
--
Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery
nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk
More information about the coldfire-gnu-discuss
mailing list