History log of /dragonfly/lib/libc/x86_64/sys/fake_sbrk.S (Results 1 – 1 of 1)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v6.2.1, v6.2.0, v6.3.0, v6.0.1, v6.0.0, v6.0.0rc1, v6.1.0, v5.8.3, v5.8.2, v5.8.1, v5.8.0, v5.9.0, v5.8.0rc1, v5.6.3, v5.6.2, v5.6.1, v5.6.0, v5.6.0rc1, v5.7.0, v5.4.3, v5.4.2
# 8618d94a 16-Feb-2019 Matthew Dillon <dillon@apollo.backplane.com>

libc - Use sbrk() system call, remove brk()

* Attempt to use the kernel sbrk() system call. If it fails
with EOPNOTSUPP, back-off to the older libc sbrk() emulation
code which uses still-presen

libc - Use sbrk() system call, remove brk()

* Attempt to use the kernel sbrk() system call. If it fails
with EOPNOTSUPP, back-off to the older libc sbrk() emulation
code which uses still-present but obsolete break() system call.

* Changes support both old and new kernels. Older kernels do not
implement the sbrk() system call, causing the call to return
-1/EOPNOTSUPP. Note that older kernels did not generate an
ENOSYS/signal for sbrk().

* sbrk() cannot support negative increments. Allow only 0 and positive
increments.

* Fix MPSAFE issues (requires new kernels) while we are here.

* Remove brk() support entirely. This was also emulated in older
kernels using break().

* These changes are necessary in order to support mmap() hinting above
RLIMIT_DATA's current value. Older kernels only support hinting above
the system maximum value (above the 32GB mark). Several languages in
dports really want to mmap() addresses below 4GB.

show more ...