Re: makesyscalls (moving forward)

[Reinoud Zandijk <reinoud%NetBSD.org@localhost>]

On Mon, Jun 15, 2020 at 02:58:31PM +0200, Kamil Rytarowski wrote:
> LLVM is an external project and only in a special case part of the
> basesystem. While there, there is the same issue with GCC sanitizers. We
> definitely don't want to request regular LLVM or GCC users building the
> toolchain to depend on TOOLDIR / BSDSRCDIR.

If you mean developers that work on the toolchain, you work with patches in
the tree in one way or another, doing pullups and the like but then the source
tree is already there so what is the problem then?

Trying to build LLVM or gcc from pkgsrc? That'll need NetBSD specific patches
anyway and they can be created on package creation/update by the developer who
has the source tree anyway or do you want the packages to create a bunch of
NetBSD specific files on the fly using the tool on package compilation on
NetBSD systems?

> > 4) some syscall bashing tools for testing etc. They are tailored anyway so
> > using a $BSDSRCDIR specfic program that is not installed is not that
> > relevant.
> I don't know what is syscall bashing tool for testing.

Wrong term i think; i meant sending the kernel random or on purpose random
ioctls and system calls to test input parameter checking. You mean this?
> We work on rumpkernel syscall fuzzers during the ongoing GSoC.

> As of today GDB, but other similar programs can/shall follow.
> 
> syscall tracers (I wrote picotrace, truss - both distributed in pkgsrc;
> there is strace)

I don't know these. Sounds like ktrace binary output displaying? Or do they
collect info in another way? Why not fix or enhance ktrace/kdump/ktruss ? ;)

> Language runtime, basically everything that is not using libc could use it
> (go, rust, D, etc).

I forgot that one yes, but this is serious feature creep going on! You want at
compilation time (of those languages) to auto generate the equivalent header
and system call stubs using the data? See below.

> For a developer it is fine to request BSDSRCDIR to be available, but for
> users (of e.g. GDB) this is certainly an overkill. makesyscalls(1) will be
> maybe up to 1MB. Just $BSDSRCDIR/sys takes around 450MB. If we want to
> depend on BSDSRCDIR for programs in pkgsrc, this is IMO a blocker.

Why would a runtime use of say gdb make use of the tool?

> Prebuilt picotrace takes less than 100kb. Adding a hard dependency on
> BSDSRCDIR would be severe overkill.

For compilation of picotrace and the likes you mean? A build in syscall table,
wich you also prefer IIRC, would hardcode it to the current installed userland
version, not the kernel version and is that preferable in pkgsrc settings?

Reinoud