Page MenuHomeFreeBSD

Remove sbrk on arm64
ClosedPublic

Authored by andrew on May 19 2016, 7:51 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Sep 30, 11:51 PM
Unknown Object (File)
Fri, Sep 27, 6:03 PM
Unknown Object (File)
Wed, Sep 18, 8:21 PM
Unknown Object (File)
Sep 12 2024, 7:28 AM
Unknown Object (File)
Sep 11 2024, 3:00 PM
Unknown Object (File)
Sep 11 2024, 3:00 PM
Unknown Object (File)
Sep 10 2024, 8:05 PM
Unknown Object (File)
Sep 9 2024, 2:10 AM

Details

Summary

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.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

andrew retitled this revision from to Remove sbrk on arm64.
andrew updated this object.
andrew edited the test plan for this revision. (Show Details)
andrew added reviewers: arm64, brooks.
andrew added a subscriber: emaste.

Can you explain the test changes?

Can you explain the test changes?

These all call sbrk(0) in an invalid attempt to find the malloc memory usage.

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.

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)?

Is it possible to fix them (possibly by eliminating some non-functioning portion of the tests)?

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?

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?

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.

In D6464#136897, @imp wrote:

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.

We could do the same on armv6 (hard-float bits only) and riscv, neither of these have had releases.

In D6464#136897, @imp wrote:

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.

We could do the same on armv6 (hard-float bits only) and riscv, neither of these have had releases.

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

Disable the specific tests that call sbrk

In D6464#136899, @imp wrote:

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.

armv6 will also need the binutils changes in D5600 before we could remove it.

brooks edited edge metadata.

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.

This revision is now accepted and ready to land.May 19 2016, 9:23 PM
emaste added a reviewer: emaste.

I'm OK with this as is, with further test fiddling potentially happening in a follow-up commit.

This revision was automatically updated to reflect the committed changes.

A bit late to the party, but I got bitten by this today - where this should be documented? sbrk(2) manpage?

A bit late to the party, but I got bitten by this today

Can you explain how?

A bit late to the party, but I got bitten by this today

Can you explain how?

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.