Page MenuHomeFreeBSD

libsbrk: add a trivial library that exposes sbrk
AcceptedPublic

Authored by brooks on Dec 12 2023, 1:16 AM.
Tags
None
Referenced Files
F103099355: D43002.id144289.diff
Wed, Nov 20, 11:33 PM
Unknown Object (File)
Wed, Nov 20, 9:07 AM
Unknown Object (File)
Sun, Nov 17, 2:57 PM
Unknown Object (File)
Thu, Nov 14, 1:45 AM
Unknown Object (File)
Wed, Nov 13, 10:52 PM
Unknown Object (File)
Wed, Nov 13, 12:59 PM
Unknown Object (File)
Wed, Nov 13, 11:58 AM
Unknown Object (File)
Wed, Nov 13, 11:56 AM
Subscribers

Details

Reviewers
kib
Summary

Having modified libc to not expose sbrk for linking, provide a library
that links to the versioned symbol and exposes sbrk for linking. This
allows software that requires sbrk to add -lsbrk to LDFLAGS to use sbrk
without allowing autoconf to overzealously find it via AC_CHECK_FUNC.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 59779
Build 56665: arc lint + arc unit

Event Timeline

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.

lib/libsbrk/sbrk.c
41
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#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]

Version sbrk symbol
Make libsbrk a filter for libc

kib requested changes to this revision.Dec 23 2023, 3:03 PM
This revision now requires changes to proceed.Dec 23 2023, 3:03 PM

Mis-handled my mouse sorry.

This revision is now accepted and ready to land.Dec 23 2023, 3:03 PM
This revision now requires review to proceed.Jun 19 2024, 11:35 PM

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

rescue/rescue/Makefile
149 ↗(On Diff #140014)

How is this chunk related to the introduction of the new library?

Build on all architectures

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

This revision is now accepted and ready to land.Oct 5 2024, 4:30 AM