This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: brk(2) trouble
- From: Roland McGrath <roland at redhat dot com>
- To: Momchil Velikov <velco at fadata dot bg>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Thu, 21 Nov 2002 17:51:04 -0800
- Subject: Re: brk(2) trouble
> How brk(2) is supposed to be implemnted ? And what's the semantics of
> "break" in a dynamically linked program anyway ?
The break follows the executable's data segment (i.e. the address of the
program's own _end), and the kernel puts mmap mappings like shared objects
far enough way to leave room for it to grow some.
On Linux, the implementation now does not initialize __curbrk to &_end.
Instead, it's uninitialized (or initialized to zero, for reasons that
aren't important to you) and sysdeps/generic/sbrk.c in this case calls
__brk(0) to set it from the kernel state before using the __curbrk value.
The Linux versions do not enforce a __minbrk value, so getting that
initialized is not an issue. I think a brk(&_start) will just happily eat
your text and data mappings in Linux.