Date: Mon, 5 Feb 2024 22:13:07 +0100 From: Paul Floyd <paulf2718@gmail.com> To: freebsd-current@freebsd.org Subject: Re: libc/libsys split coming soon Message-ID: <EFA1A96E-4EDB-4468-892B-217094A2FBCD@gmail.com> In-Reply-To: <ZcEGixWOv98DKw6y@spindle.one-eyed-alien.net> References: <Zb1tTz5LXuVQ5Caj@spindle.one-eyed-alien.net> <8a34573d-4a6c-4d5d-a771-b39279059547@gmail.com> <ZcEGixWOv98DKw6y@spindle.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi > On 5 Feb 2024, at 17:02, Brooks Davis <brooks@freebsd.org> wrote: >=20 >=20 >>> 2. It simplifies the implementation of restrictions on system = calls such >>> as those implemented by OpenBSD's msyscall(2) >>> (https://man.openbsd.org/msyscall.2). >>=20 >> That's one to ignore for tools that make syscalls outside of the libc = memory >> mapping. >=20 > Should someone implement msyscall(2) there will certainly be an opt = out > mechanism along the usual lines that uses elfctl and procctl. I was thinking more of simply not passing on such syscalls. >=20 >>> 3. It allows language runtimes to link with libsys for system call >>> implementations without requiring libc. >>=20 >> I see that pagesize is on the list of functions that are moving. = There are a >> couple of other functions that might cause me problems if libc isn't = linked. >>=20 >> Could you do a quick test with an exe linked to libsys but not libc = running >> under Valgrind memcheck, please? >=20 > Could you suggest a more concrete example? I don=E2=80=99t think that it really matters. Just an empty main(). The = important thing would be linking to libsys and not libc. A+ Paul=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EFA1A96E-4EDB-4468-892B-217094A2FBCD>