Page MenuHomeFreeBSD

Indicate the brk/sbrk are deprecated and not portable.
ClosedPublic

Authored by brooks on May 23 2018, 3:55 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Oct 2, 10:22 PM
Unknown Object (File)
Fri, Sep 27, 8:24 PM
Unknown Object (File)
Fri, Sep 27, 3:15 PM
Unknown Object (File)
Mon, Sep 23, 4:23 PM
Unknown Object (File)
Mon, Sep 16, 1:19 AM
Unknown Object (File)
Sun, Sep 15, 1:24 AM
Unknown Object (File)
Wed, Sep 11, 4:55 AM
Unknown Object (File)
Sep 9 2024, 2:29 AM

Details

Summary

Include the history of arm64 and riscv shipping without brk/sbrk.

Mention that sbrk(0) produces unreliable results.

(Per request in D6464).

Diff Detail

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

Event Timeline

saper_saper.info added inline comments.
lib/libc/sys/brk.2
180 โ†—(On Diff #42883)

typo: "reflect"

I have one question. From what I see in the code for brk() and sbrk() got removed from the C library, but the system call sys_obreak still exists, correct?

This revision is now accepted and ready to land.May 23 2018, 8:41 PM

Are there any architecture-specific reasons for removal? (Something that riscv and aarch64 cannot do but amd64 and i386 can)?

Maybe we should also hint at mmap(2) as a replacement for larger than zero sbrk(2).

Are there any architecture-specific reasons for removal?

Just a lack of backwards compatibility requirements (i.e., there are no existing FreeBSD binaries which make use of sbrk).

I have one question. From what I see in the code for brk() and sbrk() got removed from the C library, but the system call sys_obreak still exists, correct?

Hmm, that's a bug. We should remove it (or at least make it ENOSYS).

Are there any architecture-specific reasons for removal?

Just a lack of backwards compatibility requirements (i.e., there are no existing FreeBSD binaries which make use of sbrk).

Also, sbrk() is incompatible with (or at least a very poor fit with) a number of memory protection schemes. Among other things it defeats ASLR.

I have one question. From what I see in the code for brk() and sbrk() got removed from the C library, but the system call sys_obreak still exists, correct?

Hmm, that's a bug. We should remove it (or at least make it ENOSYS).

I haven't tried to call it in assembly myself, it's just my reading of D6464: Remove sbrk on arm64 and some random grepping around the code, so don't take my word.

So basically we are just taking the opportunity of the new architecture not to have to provide backward compatibility for it later?

  • Explictitly refer to mmap.
  • Refer to mmap in the right section.
This revision now requires review to proceed.May 23 2018, 9:15 PM
lib/libc/sys/brk.2
56 โ†—(On Diff #42898)

section 3?

lib/libc/sys/brk.2
56 โ†—(On Diff #42898)

grr, fixed one and added another. Will fix shortly.

lib/libc/sys/brk.2
159 โ†—(On Diff #42940)
$ groff -Tps -mdoc t.man > t.ps
mdoc warning: .Fx: Unknown FreeBSD version `11' (#159)

Ugh

mdoc(7) nitpicking :(

lib/libc/sys/brk.2
159 โ†—(On Diff #42940)

Just use

.Fx 11.0
168 โ†—(On Diff #42940)

From the point of view of readability .Fn does not seem to mix well with .Xr in formatted text.

t01.png (164ร—824 px, 2 KB)
t02.png (257ร—547 px, 4 KB)

brooks marked 5 inline comments as done.
  • Use "Fx 11.0" rather than "Fx 11"
lib/libc/sys/brk.2
168 โ†—(On Diff #42940)

Way beyond the scope of this change and too much effort for an interface people should have long since abandoned.

This revision is now accepted and ready to land.May 24 2018, 6:25 PM
This revision was automatically updated to reflect the committed changes.