This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [uClinux-dev] Re: brk(2) and stack pointer
Jivin Shaun Jackman lays it down ...
> On 4/29/06, David McCullough <david_mccullough@au.securecomputing.com>
> wrote:
> >brk, when implemented under uClinux only gives you access to a small
> >amount of memory. Typically that below the stack and above the BSS.
> >The space you get is the slack space from the kernel allocator, so it
> >can be anything from none up.
>
> When the brk is growing up towards the stack pointer, I was trying to
> figure out when brk should stop giving out memory. Anything other than
> "once you've reached the stack pointer" is an arbitrary limit.
bFlt sets the stack size, brk stops at the absolute top of the stack.
> >Typically, brk is not used on uClinux systems, though some malloc
> >implementations have used it to get the absolute most out of the RAM,
> >most tend to stick with mmap allocation,
>
> That explains a lot, actually, about how uClinux manages the heap. The
> bFLT executable format specifies a "stack space" allocation, but not a
> "heap space" allocation. I assumed the "stack space" is the total
> space allocated after the BSS, and that the brk and stack grow towards
> each other, such that the "stack space" allocation was shared by the
> heap and the stack. It makes more sense if the stack has exclusive
> access to this space, and the heap is mmap'ed.
That's how it is, no per app heap is allocated.
> newlib's default malloc for embedded systems uses brk. I believe the
> i386-linux malloc implementation can use mmap, but I don't have the
> source in front of me at the moment.
Try and track down a copy of "simple-malloc" or "malloc-simple", a
really old one lives here:
http://cvs.uclinux.org/cgi-bin/cvsweb.cgi/uClinux-dist/lib/libc/malloc-simple/alloc.c?rev=1.1.1.1;content-type=text%2Fplain
There was a version at some point that did both brk and mmap, but I
cannot recall where to find it. The version above will give you enough to
make a really simple allocator.
Cheers,
Davidm
--
David McCullough, david_mccullough@securecomputing.com, Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com