From nobody Sat Jul 01 13:26:50 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QtXzF0lwnz4kZYf for ; Sat, 1 Jul 2023 13:27:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QtXzD4r5Kz3G4w for ; Sat, 1 Jul 2023 13:27:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-51d9695ec29so2777927a12.1 for ; Sat, 01 Jul 2023 06:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1688218021; x=1690810021; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=sSBfJYJiEMjUg4DimTEw53tsMd6WATDU77DAEowm9Qw=; b=noKPYc4/OEEzNkORMxNMsW5H1gYiD9FpbQDsPRlJiFT/EVc6gVGFewg1g/WpAkfvro R1INTkGv1mKW/DbZFF/1CTZEN7aWqwophlDTsCgsvycNtVAUlO7txxuMYPuNnP9Uzjbz gDe7Bu1W1vBDnHqiNAFWFhIUigir9N6G5Prei5Xk7lgozkp1Iy0l2d15Fa9dkvYMsPwj BvPa9mkoin2czh5UAhBAYfm95UsGnwI0rz+QYEjamJDoqRj8+YshSZlAtRMtFilechgJ KUuFUP4jUI7kn+ZoqDreBVWTNgSnI+mGxRTu3L+RtRsk6Q0dvBbjiefOiBjBG12BzMt5 Qo+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688218021; x=1690810021; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=sSBfJYJiEMjUg4DimTEw53tsMd6WATDU77DAEowm9Qw=; b=O/O4CMJBZ6SYOIbMoAC9+YmU0o9xZ9GtEXbw0NinlNmcGd7yLWHEK30jc5mElcLz7Y 5ulCkuIefqKHO4JlgRL5uKhhcPSCpnyqp3KF9zkaeN1dwoCeYjFPAuWe4FgyiCIydYjR fYNKRDWq/l/RtZyNfEUW9YUMsaFj/Mi9LKsoArqhfuj4th6+MRoh6uZkf+GFL+Plquka FXcd926E91Ra2xh0EFt+CCYVzgS9+8EcmGUtTC64837+JIzoMO+ACIbBkLbHXaAsyZrG Qpb8svJrqXfOOXDqKbgszd9k+CqzByUR2Thc09ENfXbnN3Vc2fC6LDA3wrBNhioqkWSc FulQ== X-Gm-Message-State: ABy/qLZ9Kkfp1eHygbyvkI/nufE7cUN3nLpsOXVtg+jZS6QrCmAJEICS /GsL25FTRZdCpVFQ1GAm1wES6Gbcb1IZ9fL9DvfECeOpPvpXeaoyk2U= X-Google-Smtp-Source: APBJJlEuUW2Ii0l5W/8B/RKSph6kdZ1CFGcTGFHFc0DBwY+SzUX5PadRr0UGJDiEZEnPbAx+Q4dx19rNAGRPWBQnwi0= X-Received: by 2002:a05:6402:43ce:b0:516:9fef:f8e7 with SMTP id p14-20020a05640243ce00b005169feff8e7mr3043253edc.3.1688218021159; Sat, 01 Jul 2023 06:27:01 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <5f311275-e307-4e78-a479-c6d4e7f116d5@app.fastmail.com> <32a0f7e7-11b7-443e-a601-40bec7798d8f@app.fastmail.com> In-Reply-To: <32a0f7e7-11b7-443e-a601-40bec7798d8f@app.fastmail.com> From: Warner Losh Date: Sat, 1 Jul 2023 07:26:50 -0600 Message-ID: Subject: Re: How are syscall functions defined? To: Pat Maddox Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000007475a405ff6ce353" X-Rspamd-Queue-Id: 4QtXzD4r5Kz3G4w X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000007475a405ff6ce353 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Pat Maddox 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=E2=80=99t find any def= inition > > of that specific syscall function (or any other). I think the closest > > I=E2=80=99ve found is sys_jail_attach in kern_jail.c [3]. I suspect the= re=E2=80=99s > > some generation going on that defines jail_attach - but if that=E2=80= =99s the > > case, I haven=E2=80=99t 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#L1= 19 > > [3] > > > https://github.com/freebsd/freebsd-src/blob/releng/13.2/sys/kern/kern_jai= l.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/Symb= ol.map#L672 > [2] > https://github.com/freebsd/freebsd-src/blob/releng/13.2/share/mk/bsd.symv= er.mk#L43 > [3] > https://github.com/freebsd/freebsd-src/blob/releng/13.2/share/mk/bsd.lib.= mk#L253 > > --0000000000007475a405ff6ce353 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK. System calls are a pain. there's a lot of boilerpl= ate=C2=A0needed to make them all work.

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

In userland, though, the system calls live in libc. But t= here's no source file for them.
Instead, libc's sys/Makef= ile.inc includes sys/sys/syscall.mk, whic= h is also generated above,
which has a list of all the system cal= l files to create. Dependency rules in sys/Makefile.inc
cause tho= se .o's to be created with this rule:
${SASM}:
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 printf '/* %sgenerated by libc/sys/Makefile.inc */\n&= #39; @ > ${.TARGET}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 printf '#include = "compat.h"\n' >> ${.TARGET}
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 printf '#include "SYS.h"\nRSYSCALL(${.PREFIX})\n' >= ;> ${.TARGET}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 printf =C2=A0${NOTE_GNU_STA= CK} >>${.TARGET}

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

/* jail_attach.S gen= erated=C2=A0by libc/sys/Makefile.inc */
#incldue "compat.h&q= uot;
#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) =C2=A0ENTRY(__sys_##name); =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0\
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 WEAK_REFERENCE(__sys_##name, name); =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 WEAK_REFERENCE(__sys_##name, _##name); = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mov $SYS_##name,%eax; KERN= CALL; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 jb HIDENAME(cerror); ret; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 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. Symb= ol versions are beyond
the scope of this post.

Warner

On Sat, Jul 1, 2023 at 5:23=E2=80=AFAM 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=E2=80=99t find any de= finition
> of that specific syscall function (or any other).=C2=A0 I think the cl= osest
> I=E2=80=99ve found is sys_jail_attach in kern_jail.c [3]. I suspect th= ere=E2=80=99s
> some generation going on that defines jail_attach - but if that=E2=80= =99s the
> case, I haven=E2=80=99t been able to track it down.
>
> Can someone point me to how the C function gets defined?
>
> Thanks,
> Pat
>
> [1]
> https://g= ithub.com/freebsd/freebsd-src/blob/releng/13.2/sys/kern/syscalls.master#L23= 07
> [2]
> https://github.com/f= reebsd/freebsd-src/blob/releng/13.2/sys/sys/jail.h#L119
> [3]
> https://githu= b.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 th= e linker [3], which I assume maps the symbols in the resulting binary. I in= tend to experiment with that a bit, but I think that makes sense.

Pat

[1] https://gith= ub.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.c= om/freebsd/freebsd-src/blob/releng/13.2/share/mk/bsd.lib.mk#L253

--0000000000007475a405ff6ce353--