Re: [PATCH] Define _sbrk_r() even when MALLOC_PROVIDED is defined

[Jeff Johnston <jjohnstn at redhat dot com>]

On 07/18/2011 03:24 AM, Corinna Vinschen wrote:
> On Jul 16 22:44, Matt Johnson wrote:
> > Hi All,
> >      I ran into an issue when compiling the SPEC2000 version of gcc
> > using my newlib-based toolchain.  I define MALLOC_PROVIDED so that I
> > can use my own dlmalloc/nedmalloc-based implementation, but gcc
> > still calls sbrk(), presumably to get some idea of how much memory
> > it used.  sbrk() unconditionally calls _sbrk_r(), which in turn
> > calls the syscall stub _sbrk().  The problem is that sbrk() is not
> > left out of the library when MALLOC_PROVIDED is defined, but
> > _sbrk_r() *is*.  So I build my libc.a, but then gcc fails to link
> > because of an unresolved symbol for _sbrk_r().  My guess is that
> > _sbrk_r() should still be defined under MALLOC_PROVIDED so that
> > sbrk() can use it, even if its other caller, newlib's stock malloc,
> > doesn't call it anymore.  Attached is a patch to make it so.
> > -Matt
>
> I think the other way around is right, if MALLOC_PROVIDED is defined,
> neither sbrk nor _sbrk_r should be defined in newlib.
>
> Jeff?

IMO MALLOC_PROVIDED does not imply _sbrk_r-is-provided.  While it is 
true that newlib won't internally refer to _sbrk_r and thus it isn't 
needed by newlib, that doesn't exclude the fact that code may want to 
call the syscall directly (as in this case) and if the configuration has 
requested that newlib build libc/syscalls, then support should be 
provided as per normal syscalls.

-- Jeff J.