This is an incomplete proof of concept of a library to expose sbrk. One could also expose brk, but AFACT there are no users of it. I've done some simple testing with explicit linkage and LD_LIBRARY_PATH. In that context it seems to work.

It's not clear to me that this would actually belong in the base system, on one hand it's trivial, on the other hand it might be a better fit in ports since there are only two sbrk using tests and no programs in the tree.

This sbrk symbol should be versioned as well.
Also, the library might be filter for libc.

In D43002#980521, @kib wrote:

This sbrk symbol should be versioned as well.

I don't object to doing that, but I'm not super convinced it's useful. There will never be a change to sbrk's interface. Should it be FBSD_1.0 like it is in libc or FBSD_1.8 because it's from FreeBSD 15?

Also, the library might be filter for libc.

That would make it linkable by default which would cause the problem I'm trying to avoid.

In D43002#980538, @brooks wrote:

In D43002#980521, @kib wrote:

This sbrk symbol should be versioned as well.

I don't object to doing that, but I'm not super convinced it's useful. There will never be a change to sbrk's interface. Should it be FBSD_1.0 like it is in libc or FBSD_1.8 because it's from FreeBSD 15?

FBSD_1.0. dlvsym() should work unchanged for this lib.

Also, the library might be filter for libc.

That would make it linkable by default which would cause the problem I'm trying to avoid.

But only if -lsbrk is provided to linker. Isn't it the goal?

Also, what about static linking? Should the symbol still be resolved from libc.a or we need libsbrk.a as well?

[Just in case, libdl.so is filter]

Why not provide the symbol and lib on aarch64/riscv as well? It only makes porting sw harder IMO.

In D43002#1041396, @kib wrote:

Why not provide the symbol and lib on aarch64/riscv as well? It only makes porting sw harder IMO.

I've ahead and done this and added D46953 to enable break(2).