Re: How are syscall functions defined?

OK. System calls are a pain. there's a lot of boilerplate needed to make
them all work.

So, it's been automated. The process starts after you add a system call to
syscalls.master.
'make sysent' is run which creates a number of different files. It creates
the kernel glue.
These glue files are then committed to the tree. On the kernel side we have
sys/kern/init_sysent.c which has the 'sysent' array which is used to
dispatch the system
calls. sys/kern/syscalls.c has the names, and sys/kern/systrace_args has
information
for dtrace decoding them.

In userland, though, the system calls live in libc. But there's no source
file for them.
Instead, libc's sys/Makefile.inc includes sys/sys/syscall.mk, which is also
generated above,
which has a list of all the system call files to create. Dependency rules
in sys/Makefile.inc
cause those .o's to be created with this rule:
${SASM}:
        printf '/* %sgenerated by libc/sys/Makefile.inc */\n' @ > ${.TARGET}
        printf '#include "compat.h"\n' >> ${.TARGET}
        printf '#include "SYS.h"\nRSYSCALL(${.PREFIX})\n' >> ${.TARGET}
        printf  ${NOTE_GNU_STACK} >>${.TARGET}

which is where the source winds up: in the object tree as jail_attach.S
likely
with the contents (generated by hand):

/* jail_attach.S generated by libc/sys/Makefile.inc */
#incldue "compat.h"
#include "SYS.h"
RSYSCALL(jail_attach)
.section .note.GNU-stack,"".%%progbits

The different __sys_jail_attach wrapping for the threading
libraries also is part of the RSYSCALL macro, for example amd64:
#define RSYSCALL(name)  ENTRY(__sys_##name);                            \
                        WEAK_REFERENCE(__sys_##name, name);             \
                        WEAK_REFERENCE(__sys_##name, _##name);          \
                        mov $SYS_##name,%eax; KERNCALL;                 \
                        jb HIDENAME(cerror); ret;                       \
                        END(__sys_##name)

The System.map file, etc, all know that this is generated, and is used to
put the symbols in the proper version area. Symbol versions are beyond
the scope of this post.

Warner

On Sat, Jul 1, 2023 at 5:23 AM Pat Maddox <pat@patmaddox.com> wrote:

> On Sat, Jul 1, 2023, at 3:11 AM, Pat Maddox wrote:
> > jail_attach is defined in syscalls.master [1] which generates a
> > declaration in jail.h [2]. Try as I might, I can’t find any definition
> > of that specific syscall function (or any other).  I think the closest
> > I’ve found is sys_jail_attach in kern_jail.c [3]. I suspect there’s
> > some generation going on that defines jail_attach - but if that’s the
> > case, I haven’t been able to track it down.
> >
> > Can someone point me to how the C function gets defined?
> >
> > Thanks,
> > Pat
> >
> > [1]
> >
> https://github.com/freebsd/freebsd-src/blob/releng/13.2/sys/kern/syscalls.master#L2307
> > [2]
> >
> https://github.com/freebsd/freebsd-src/blob/releng/13.2/sys/sys/jail.h#L119
> > [3]
> >
> https://github.com/freebsd/freebsd-src/blob/releng/13.2/sys/kern/kern_jail.c#L2340
>
> Symbol.map [1] is used to produce a version map [2] which is then fed to
> the linker [3], which I assume maps the symbols in the resulting binary. I
> intend to experiment with that a bit, but I think that makes sense.
>
> Pat
>
> [1]
> https://github.com/freebsd/freebsd-src/blob/releng/13.2/lib/libc/sys/Symbol.map#L672
> [2]
> https://github.com/freebsd/freebsd-src/blob/releng/13.2/share/mk/bsd.symver.mk#L43
> [3]
> https://github.com/freebsd/freebsd-src/blob/releng/13.2/share/mk/bsd.lib.mk#L253
>
>