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

[Corinna Vinschen <vinschen at redhat dot com>]

On Jul 18 12:05, Jeff Johnston wrote:
> 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.

I thought the MALLOC_PROVIDED idea was so that the target provides
all memory allocation, but I see now that this makes not as much
sense as having a system-provided sbrk.  I've checked the patch in.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat