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)
Feb 28 2024, 3:54 AM
Unknown Object (File)
Jan 29 2024, 3:11 PM
Unknown Object (File)
Jan 21 2024, 9:28 AM
Unknown Object (File)
Dec 22 2023, 11:08 PM
Unknown Object (File)
Dec 13 2023, 6:34 AM
Unknown Object (File)
Nov 27 2023, 6:11 PM
Unknown Object (File)
Nov 11 2023, 11:35 PM
Unknown Object (File)
Oct 19 2023, 4:01 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

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 16790
Build 16675: arc lint + arc unit

Event Timeline

saper_saper.info added inline comments.
lib/libc/sys/brk.2
180

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

section 3?

lib/libc/sys/brk.2
56

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

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

Ugh

mdoc(7) nitpicking :(

lib/libc/sys/brk.2
156

Just use

.Fx 11.0
165

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
165

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.