splitting libc -> libc + libsys and static linking

[Brooks Davis]

On Tue, Apr 03, 2018 at 04:44:10PM -0400, Shawn Webb wrote:
> On Tue, Apr 03, 2018 at 08:32:10PM +0000, Brooks Davis wrote:
> > We (mostly Ali) are working on a patch to to split the actual syscalls
> > (__sys_<foo>) out of libc and into a libsys.  For dynamic linking,
> > this is fairly straightforward (link libc against libsys, maybe as a
> > filter).  For static linking, I'm looking for feedback on the right
> > approach.  Do we link libsys.a into libc.a?  Do we try to teach all the
> > compilers to add -lsys?  I'm pretty sure we don't modify all the ports
> > that statically link programs.  Is there some easy approach I'm missing?
> 
> I'm curious about the reasoning behind this change. Could you explain
> in more detail why you'd like to create a libsys?

In CheriBSD I use something like this to let me use the same libc
inside and outside sandboxes while varying the syscall implementation.
Ali is (IIRC) using it in a record and playback framework.  It could
potentially let us link a libsys_pic.a into libthr.so and rtld to
eliminate the need for syscall(2).  It could also ease experimentation
with alternative syscall invocation methods (e.g. I've got a branch of
CheriBSD where the ability to make a given syscall is controlled by
possession of an unforgable token.)

Having a clear interface in a separate library makes it easier to know
what to replace and gives a clear place to do it.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20180403/c7ec6fcf/attachment.sig>