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>
index | next in thread | previous in thread | raw e-mail
Hi > On 5 Feb 2024, at 17:02, Brooks Davis <brooks@freebsd.org> wrote: > > >>> 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). >> >> That's one to ignore for tools that make syscalls outside of the libc memory >> mapping. > > 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. > >>> 3. It allows language runtimes to link with libsys for system call >>> implementations without requiring libc. >> >> 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. >> >> Could you do a quick test with an exe linked to libsys but not libc running >> under Valgrind memcheck, please? > > Could you suggest a more concrete example? I don’t think that it really matters. Just an empty main(). The important thing would be linking to libsys and not libc. A+ Paulhelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EFA1A96E-4EDB-4468-892B-217094A2FBCD>