This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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?


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]