This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: brk(2) and stack pointer
- From: Russell King - ARM Linux <linux at arm dot linux dot org dot uk>
- To: Shaun Jackman <sjackman at gmail dot com>
- Cc: uClinux development list <uClinux-dev at uclinux dot org>, newlib at sources dot redhat dot com
- Date: Fri, 28 Apr 2006 21:03:08 +0100
- Subject: Re: brk(2) and stack pointer
- References: <7f45d9390604280853tf742eb6qfc8e213b78c7df03@mail.gmail.com>
On Fri, Apr 28, 2006 at 09:53:53AM -0600, Shaun Jackman wrote:
> I'm implementing ARM Linux support for the newlib libc. When
> implementing brk(2), is it reasonable to check that the requested
> end_data_segment is below the stack pointer, or should the brk(2)
> implementation allow for a stack that's been allocated below the heap
> in memory?
Why do you need to care about this? I suspect if you do care about it,
you're in for all sorts of games - think about the case where you
malloc some memory for a stack, and then use clone() to create a new
thread whose stack is in that malloc'd memory. That would quite
probably be below the current brk, so with your code would cause
brk() to fail.
The default stack which the kernel gives you will be contained within
one "VMA", and the zero'd data segment (edata to brk) will be within
another - the two of which will not ever be allowed to overlap. So
you can consider that this case is dealt with by the kernel.