sbrk was last in POSIX 12 years ago, and even then it was deprecated,
as such remove it from arm64. The major ports have been tested to
work with this, e.g. binutils has been forced to not use sbrk for around
6 weeks.
Details
Details
- Reviewers
brooks emaste ngie - Group Reviewers
arm64 - Commits
- rS300303: Remove brk and sbrk from arm64. They were defined in The Single UNIX
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
This has been extraced from D5600, there are a few more callers of sbrk in the tree. These will need to be checked for cross building on arm64, but are not needed to build arm64.
Comment Actions
These all call sbrk(0) in an invalid attempt to find the malloc memory usage.
Is it possible to fix them (possibly by eliminating some non-functioning portion of the tests)?
Comment Actions
dir_test has a test where it's using it to check for memory leaks. I don't think there is an easy way to fix it, but could disable it on arm64.
mlock_test is trying to get an invalid pointer to see if mlocking it fails, do we have a way to generate a non-NULL invalid pointer?
Comment Actions
dir_test has a test where it's using it to check for memory leaks. I don't think there is an easy way to fix it, but could disable it on arm64.
Yeah, that's what I mean: keep the rest of the functionality, but remove the portions that are trying to do something with sbrk.
mlock_test is trying to get an invalid pointer to see if mlocking it fails, do we have a way to generate a non-NULL invalid pointer?
I'm not sure of a simple and portable way to do so, but perhaps we could have a bunch of machine-dependent constants for invalid userspace pointers?
Comment Actions
While I'm super-sad to see it go, nothing should be using it these days, and there's no 'long dead hand of the binary past' reason to keep it.
Comment Actions
We could do the same on armv6 (hard-float bits only) and riscv, neither of these have had releases.
Comment Actions
riscv for sure. armv6 if we remove it, then we'll break the ability to generate softabi libraries that match. Maybe not a big deal since those are just a transition thing anyway.
Warner
Comment Actions
The t_mlock.c test could be made to not rely on sbrk(), but otherwise I think this is ready to go.
| contrib/netbsd-tests/lib/libc/sys/t_mlock.c | ||
|---|---|---|
| 223 ↗ | (On Diff #16590) | The easy way to do this is to mmap() a page, then munmap() it and use the no longer valid pointer. |
Comment Actions
I'm OK with this as is, with further test fiddling potentially happening in a follow-up commit.
Comment Actions
A bit late to the party, but I got bitten by this today - where this should be documented? sbrk(2) manpage?
Comment Actions
I'd say nothing special - "another broken port" - While working on https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211164 I tried to unbreak aarch64 for Korn Shell, but it uses libast which
provides its own malloc implementation. It got patched to use mmap() and it does not allocate memory with sbrk now, but it still needs sbrk(0) to check if the address is within its bounds.
Upstream development is kind of at the crossroads so it is hard to discuss things there. There are some issues with switching to libc malloc which need to be resolved first.
The error message during compilation was hiding this a bit - due to linker error iffe configuration scripts (think "autoconf") didn't generate appropriate headers so the failure was about
some undefined symbol.