Re: [uClinux-dev] Re: brk(2) and stack pointer

[David McCullough <david_mccullough at au dot securecomputing dot com>]

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