From nobody Sat Mar 22 02:11:26 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZKN9G4nG6z5r4CP for ; Sat, 22 Mar 2025 02:11:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZKN9G2brXz3nvN for ; Sat, 22 Mar 2025 02:11:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1742609499; bh=Yi49Bz7JcRVmjeE1QUuxXu5Vilz4rLNcli8xhTNdTiQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=oyWUjvuifW0+CdmoS0kvr0TyCAfFuacdZdYxwZerlK5L2PV4sEf1RAZ27K0PKGECPgwZ7DXgn+Kvmdf49ap3qzbGmX5UWj8amXbG+ia8u5kT5dYBk5922QquSq4cYMCGNDMX6RH1zhcKVgNdukj6+Ia/ihz/6Y3q8pP98GB/fqKoRaneoVZj3zwPKBLuWQzFtrWawZEV5uNpFTXox0Frz5HzwDY0HZzVaGRNE5TKZniSLpHZkc+qpMNrUq0TVqbBLD7gbjVkee5ZPlmuaGZrURPfpoWQO9QS4K01RR0/XyaRyKjf2TH7uegl7Crzh8is7RVJ2BApHBKNaDE/EnD/6w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1742609499; bh=NSqRy4lmNbVgWCAMgBIB8oG9UIZfN6COV5H7VtrRHqm=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=eNEGxaMu7WLjiwOUffxm9QT47exyLWMkgyf0QyCWXRWWkPkq9x8KJxv2T4PJI+JQDpQevw6QR2MsHokU0BCRC3DhXAmm4NNJPljKmLL43wtkSusvXzPWmd2ByD6FGRLax0KoJ6QwAhwc8SNAs+hXiWnGY7+VEwMc2y8D42PewicHi4ZJ2DsWFW/56QIF/JVabR14d/yU/GwHwgfmbsN5YPItP+Kog/j119aYGmhWNUb8AChoYcShTiEnCdiYH3ZXX8lwpkrqvK64feX/C3sE6p/hRTnOCxk9WOcqoMb9LxmeFlyNOP5EBjsEAILVXNcu78bJolGA6mhyDP6tGyk/2w== X-YMail-OSG: jIcN4aAVM1msBfCQrJVxbANTeT0_u0uGsdMUEkbSZU_Lb8t82d.eypFb.BxGrwN bjAptoH_cswt1LiBq3o0MYKtVEGsy_E427588FcGyLCVIjYQCwZVMQ6DEhD6gnDsUw2M2dB46rgc ki4uRUd8x4hOBboXX8cpquPKhP9Ynm2erm1jy.TRRRycEahUWysSEJNYd5XVwZ64Xt9BwCtdHE2i Ef0YcrHALE1BgNrYzoYhKih79JjxPN.5yIh_ktMDG.usIa7TfgXqoeicU6UngtoBVccY_HAmlbdt FmSrpXz4hNb.cGNvSfCg5lAPY0pjR8D2jOsHpEpeBVWSK5M7ZJ4uXtk8OwpgllNXNcgsoq7noTkc OgMig81cgRTz3UodbVOyrKm_VbqxqhgUupXfiFE6Ota0duzNDpLEJmhC_YYJfULpwa1MGKtMBOJ8 5KcwN8y3g_IgsLmHZMPu_jrcS74RAc93Cn7SX94G3fPcB.1Ngl.6WCdpQoG47EB37TRFvrNG0st1 uW158OZRDXU2aZRfElI.1jN._esSDcm08GoZ1ywxa7v0oauoQxToUHyGrzpWmkpJIwwSFKa8suaV aKqRDByTIwEllwYrjmouHrS0JEf2PFqWuk2rnJSRGT85TNdpQbow.qyE9DwJTW1rnmqe9Np4tfRb f95K2jxbmFadeOhsrK6xf8t54rgpEItaIuuNjDv6Uo.npR3mC_6b1_8LDS1QGfKUZFA5lWoTQfcc 7lwsr4zdx47XmqCNzznyFwvH9Bd4F02PdfX66yI0zFXQWAMvpjqofnriqiTtd45rwTFxz0rdMUtw 7Q6kc0DZf6NW4LkBiYirixYyAIAQnB0Wkuaj4C6VMSgQVTlMjvG.ZitneHoL2mtv9PdeyCp9luo8 .55I.HNYCCnl8oa6vcV7uJ6YisCEfqlLQ1ehMtwlnAkm60MDmAjgS4_OecD_ucfk8st59cXzIuBj 6MdoYEWes5OKATyCu5iZbqLcb05VYQuQpNpDKcE9NrbiwJCU1s8HDnL6gSlW8BnceqP.nRvk7EYu gElray3w0ByzjZFNUtGs5_rEjeWIOZTUbmDfCv2F5J7JCfYNLGFjTNpuktfeJdrqj5Ln3XfZ.20k U.JT9V3oS3qm46wwWcCSPoxKbxeZEIN.aQAYKALAcyfuDYUUgvgxX2jc54zeYZJ0xIw8Ehu..lhH RpmpVZXzndtCfkSNfUa0BB2dCtj9BIi9lUzXUsjz1j0uyCkOdOMbUbO3gKXxMqeA_LJFp6.CuBAC 0hF9ap4krsG3qlvJbA5VYny.tEobDCrYJ1xC8jU.giyk39nZArkHX_FjrLCFPhdxxWriv2qeFh2c xBGGm6rBY5pwSIBlBkAhnXTMkGlni237AfOVpn5r2Cb7h1NQQ.OUn3k5XINl3Y5PQFwzQ8Zv7hpr BkeORxO4dZpkhOUfveLZEgkpFWyjBEselyN58jsPd18eETZbYqd6MK2mQ3dDDFil38.2yi_rrzv. XCHbQ7Qkr9YkMz85w6425_dowvlzdeFtZiObDEdBi8Yn56b99oAvYIBW850m5S1bkfQLDfcNlVS6 JgIHCD4jBHQi8pSAm82z97qBkAtpB6pBrUrerZ_3i7x7_m3TjUY2xxVZQvYWZuJCbdyOmEh_Le4H 4cxTTitvnU1lX6aH.XEqIETLVLNNC7k8dATmeuLHkmYVQ7Aw_Wo8JEi8LaddcBT2TgOIzH78DFCO H5RFTPcSeIXyBJtR1gYwhUvJk4NZFtl7R7e8F5PJfTV1CAy3z_9J2xo5Or7o8.nnchkKIOBHPOlz iNVlHO_.kQLSdndIa3aj_5GdWkH2vopzMLqHJhCztMt68cQmolk1U3QgbSgRbqrrzVX5Yg3h4gML 45EdebrmqohS5ae5FAG8XmD7PFrkU.29mTHHHzpKiDsQWpskSnqngX8aEjU6I9CoSqIYxWF5dcu. c2k.A23d6FwV9xW.3LcoDtxm1dO2ox_f24rOcrd2EDYxva9lwdamYjKRWAWw.kxGoIXYFxOBXcw9 eBhMVL4FaKi.UPeAnInzGQ3u2U21Mjp1.Q_wrI0gvTpBoUXRr55tsHNM1fFaIOBqsa7Lp02QtRgU t96bHM13iApSXAXGvUpT9lRqmI29vroOq1JEkAUgsktd29_bHCnb.64o0Md7QZOTbKoAo5ml0QQO vwwtdbycX.iXRHJs1iZkifH7rlQug2sfXiaE2aqmFTEsFFPcTiPzHc_.PGCsIbAsxDr2box0ydGH 6a5fw3FUfnjyU9Ogtrk.b1gqy2VFEyywBhxkmhD5H2.1GDS2yjUxerHEgAz_SoTGTJZfXFb_YY8v B2q7s3A-- X-Sonic-MF: X-Sonic-ID: 6e0fd70a-c54c-4a7f-a1a4-22769e0d03a8 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 22 Mar 2025 02:11:39 +0000 Received: by hermes--production-gq1-7d5f4447dd-7ttzk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4bf88a20442d86bc7b0dde46cef7ea7f; Sat, 22 Mar 2025 02:11:36 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\)) Subject: Re: The lib{c,sys} split in main: will man pages be updated for 15.0-RELEASE? From: Mark Millard In-Reply-To: Date: Fri, 21 Mar 2025 19:11:26 -0700 Cc: FreeBSD Current , Brooks Davis Content-Transfer-Encoding: quoted-printable Message-Id: <895331A9-74BD-4D00-BEF6-E0B549FA7BAA@yahoo.com> References: <271975F8-802F-4A30-BBF6-AEA5BAA97C54.ref@yahoo.com> <271975F8-802F-4A30-BBF6-AEA5BAA97C54@yahoo.com> To: Konstantin Belousov X-Mailer: Apple Mail (2.3826.400.131.1.6) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4ZKN9G2brXz3nvN X-Spamd-Bar: ---- On Mar 21, 2025, at 17:43, Konstantin Belousov = wrote: > On Fri, Mar 21, 2025 at 02:30:40PM -0700, Mark Millard wrote: >> Under: >>=20 >> # 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 >>=20 >> Looking, I see: >>=20 >> # 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) >> . . . >>=20 >> But: >>=20 >> # man -K "libsys, -l" | more >> #=20 >>=20 >> (So nothing references libsys in a similar way.) >>=20 >> # readelf -drs /lib/libsys.so.7 | sort -k8,8 | grep "\<_*errno\>" >> 633: 000000000001d328 4 OBJECT GLOBAL DEFAULT 28 = errno@FBSD_1.0 (2) >>=20 >> # readelf -drs /lib/libc.so.7 | sort -k8,8 | grep "\<_*errno\>" >> #=20 >>=20 >> # man errno >> INTRO(2) FreeBSD System Calls Manual = INTRO(2) >>=20 >> NAME >> intro, errno =E2=80=93 introduction to system calls and their = error numbers >>=20 >> LIBRARY >> Standard C Library (libc, -lc) >>=20 >> SYNOPSIS >> #include >> #include >> . . . >>=20 >> (So "libc, -lc" is still referenced for errno in the man page.) >>=20 >> (errno is just used as an example above.) >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. =3D=3D=3D Mark Millard marklmi at yahoo.com