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
signature.asc
Description: PGP signature
