Re: [patch] libmudflap, freebsd malloc issue

[James E Wilson <wilson at specifix dot com>]

On Wed, 2005-08-17 at 18:42, Frank Ch. Eigler wrote:
> It's not quite clear to me how different this is from mallocs that are
> entirely implemented in terms of mmap.  

We know that the linux malloc can call mmap, so I don't think this has
anything to do with malloc implementations.  I think the issue here is
how the standard C library is constructed, though I haven't tried
looking into the details.  With glibc, the real malloc calls the real
mmap always.  With FreeBSD, the real malloc calls the wrapped mmap
always.  And thus on FreeBSD, we must short circuit the wrapped mmap to
the real mmap when we are inside the wrapped malloc.  Naive libraries,
like newlib, will probably function like the FreeBSD library in this
respect.

> In any case, what would just
> using the "reentrant" state do in your scenario?  The intention would
> be to let the mmap wrapper call right to the system mmap and not
> allocate tracking data.

The comments I added to mf-impl.h explains my thinking here.

The reentrant state is used to determine when a mudflap wrapper routine
accidentally calls another wrapper routine.  This indicates an error
internal to mudflap.  mf_reentrancy is incremented, and the value is
printed at the end to indicate how many times this error occurred.

In the malloc case, there is no libmudflap internal error, and hence
mf_reentrancy should not be incremented.  So I made this a separate
state.

We could certainly use the same reentrant state here.  This would make
the BEGIN_PROTECT macro simpler and more efficient.  The only loss here
is that we can no longer tell the difference between reentrancy internal
to mudflap, and reentrancy because of how the C library works.  If we
don't care about this, then this may be the better option because there
will be less overhead here.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com