On Mar 21, 2025, at 17:43, Konstantin Belousov <kostik...@gmail.com> wrote:
> On Fri, Mar 21, 2025 at 02:30:40PM -0700, Mark Millard wrote: >> Under: >> >> # uname -apKU >> FreeBSD 7950X3D-ZFS 15.0-CURRENT FreeBSD 15.0-CURRENT #4 >> main-n275926-a54a240c1b57-dirty: Thu Mar 13 00:44:25 PDT 2025 >> root@7950X3D-ZFS:/usr/obj/BUILDs/main-ZNV4-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG >> amd64 amd64 1500034 1500034 >> >> Looking, I see: >> >> # man -K "libc, -l" | more >> /usr/share/man/man2/_Fork.2.gz: Standard C Library (libc, -lc) >> /usr/share/man/man2/__syscall.2.gz: Standard C Library (libc, -lc) >> /usr/share/man/man2/_exit.2.gz: Standard C Library (libc, -lc) >> /usr/share/man/man2/_umtx_op.2.gz: Standard C Library (libc, -lc) >> . . . >> >> But: >> >> # man -K "libsys, -l" | more >> # >> >> (So nothing references libsys in a similar way.) >> >> # readelf -drs /lib/libsys.so.7 | sort -k8,8 | grep "\<_*errno\>" >> 633: 000000000001d328 4 OBJECT GLOBAL DEFAULT 28 errno@FBSD_1.0 (2) >> >> # readelf -drs /lib/libc.so.7 | sort -k8,8 | grep "\<_*errno\>" >> # >> >> # man errno >> INTRO(2) FreeBSD System Calls Manual >> INTRO(2) >> >> NAME >> intro, errno – introduction to system calls and their error numbers >> >> LIBRARY >> Standard C Library (libc, -lc) >> >> SYNOPSIS >> #include <sys/syscall.h> >> #include <errno.h> >> . . . >> >> (So "libc, -lc" is still referenced for errno in the man page.) >> >> (errno is just used as an example above.) > > First, libsys does not participate in the 'official' ABI of the FreeBSD > userspace. This is indicated, in particular, by the man pages, which > clearly and correctly state that syscall stubs symbols are supposed to > be provided by libc, and apps must link to libc to get them. > > Libsys is the internal implementation detail which ABI is the subject to > change if it is ever exposed in more formal way. I particularly do not > think that traditional Unix ABI/API with 0/-1 and errno is good fit for > libsys. > > Second, errno itself is very complicated and irrelevant thing. The > symbol really should not be referenced by any ABI-compliant binary > or dso, and it is provided only for formal ABI compat. Since long > time, errno is defined as *__error(), and this is the current ABI for > it. > > Since errno is an object and exported from dso (lets put aside libc vs > libsys ATM), the reference to it ends up with the same sized object > allocated in the referencing object, and with the COPY relocation. Now, > and this is the worst part, it is indeed impossible to keep ABI of errno > (in the part that the symbol is copied from libc and not libsys) with > the libsys split, and still allow the main thread to directly access the > errno location to get correct syscall error values. As result, errno > is copied from libsys. > > So formally we somewhat break ABI, but I do think that this is the least > possible breakage to still have (future) benefits of libsys. Thanks for the notes. Part of the problem with picking examples is that they can end up being over-specific, with some extra context not intended ending up as interfering. It looks like my example use of errno has that problem. There might have been some better example to use. I think that: QUOTING YOU ABOVE This is indicated, in particular, by the man pages, which clearly and correctly state that syscall stubs symbols are supposed to be provided by libc, and apps must link to libc to get them. END QUOTE is what drives the documentation: not where one would find things when looking at the implementation but where one references to link things is the general criteria for what is being documented. Under that criteria, things stay as they are as far as I can tell. That explains what I was looking for as far as what to expect of the documentation. The recent environ/__progname issue's return in stable/14 for ports and my looking around related to it is the context that lead to my question. Although, like errno, they are not directly what my question was about: they were just why I was looking at the documentation at all. Thanks again. === Mark Millard marklmi at yahoo.com
