Date: Sat, 1 Jul 2023 07:26:50 -0600 From: Warner Losh <imp@bsdimp.com> To: Pat Maddox <pat@patmaddox.com> Cc: freebsd-hackers@freebsd.org Subject: Re: How are syscall functions defined? Message-ID: <CANCZdfrrxn6kh%2BTzkNdkQGhPPE_Zser2QaPDqHjMTO2PaUvf4A@mail.gmail.com> In-Reply-To: <32a0f7e7-11b7-443e-a601-40bec7798d8f@app.fastmail.com> References: <5f311275-e307-4e78-a479-c6d4e7f116d5@app.fastmail.com> <32a0f7e7-11b7-443e-a601-40bec7798d8f@app.fastmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <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 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
<div dir=3D"ltr">OK. System calls are a pain. there's a lot of boilerpl=
ate=C2=A0needed to make them all work.<div><br></div><div>So, it's been=
automated. The process starts after you add a system call to syscalls.mast=
er.</div><div>'make sysent' is run which creates a number of differ=
ent files. It creates the kernel glue.</div><div>These=C2=A0glue files are =
then committed to the tree. On the kernel side we have</div><div>sys/kern/i=
nit_sysent.c which has the 'sysent' array which is used to dispatch=
the system</div><div>calls. sys/kern/syscalls.c has the names, and sys/ker=
n/systrace_args has information</div><div>for dtrace decoding them.</div><d=
iv><br></div><div>In userland, though, the system calls live in libc. But t=
here's no source file for them.</div><div>Instead, libc's sys/Makef=
ile.inc includes sys/sys/<a href=3D"http://syscall.mk">syscall.mk</a>, whic=
h is also generated above,</div><div>which has a list of all the system cal=
l files to create. Dependency rules in sys/Makefile.inc</div><div>cause tho=
se .o's to be created with this rule:</div><div>${SASM}:<br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 printf '/* %sgenerated by libc/sys/Makefile.inc */\n&=
#39; @ > ${.TARGET}<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 printf '#include =
"compat.h"\n' >> ${.TARGET}<br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 printf '#include "SYS.h"\nRSYSCALL(${.PREFIX})\n' >=
;> ${.TARGET}<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 printf =C2=A0${NOTE_GNU_STA=
CK} >>${.TARGET}<br></div><div><br></div><div>which is where the sour=
ce winds up: in the object tree as jail_attach.S likely</div><div>with the =
contents (generated by hand):</div><div><br></div><div>/* jail_attach.S gen=
erated=C2=A0by libc/sys/Makefile.inc */</div><div>#incldue "compat.h&q=
uot;</div><div>#include "SYS.h"</div><div>RSYSCALL(jail_attach)</=
div><div>.section .note.GNU-stack,"".%%progbits</div><div><br></d=
iv><div>The different __sys_jail_attach wrapping for the threading</div><di=
v>libraries also is part of the RSYSCALL macro, for example amd64:</div><di=
v>#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\<br>=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 \<br>=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\<br>=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 \<br>=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 \<br>=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)<br></div><d=
iv><br></div><div>The System.map file, etc, all know that this is generated=
, and is used to</div><div>put the symbols in the proper version area. Symb=
ol versions are beyond</div><div>the scope of this post.</div><div><br></di=
v><div>Warner</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cl=
ass=3D"gmail_attr">On Sat, Jul 1, 2023 at 5:23=E2=80=AFAM Pat Maddox <<a=
href=3D"mailto:pat@patmaddox.com">pat@patmaddox.com</a>> wrote:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Jul 1, 2023, at=
3:11 AM, Pat Maddox wrote:<br>
> jail_attach is defined in syscalls.master [1] which generates a <br>
> declaration in jail.h [2]. Try as I might, I can=E2=80=99t find any de=
finition <br>
> of that specific syscall function (or any other).=C2=A0 I think the cl=
osest <br>
> I=E2=80=99ve found is sys_jail_attach in kern_jail.c [3]. I suspect th=
ere=E2=80=99s <br>
> some generation going on that defines jail_attach - but if that=E2=80=
=99s the <br>
> case, I haven=E2=80=99t been able to track it down.<br>
><br>
> Can someone point me to how the C function gets defined?<br>
><br>
> Thanks,<br>
> Pat<br>
><br>
> [1] <br>
> <a href=3D"https://github.com/freebsd/freebsd-src/blob/releng/13.2/sys=
/kern/syscalls.master#L2307" rel=3D"noreferrer" target=3D"_blank">https://g=
ithub.com/freebsd/freebsd-src/blob/releng/13.2/sys/kern/syscalls.master#L23=
07</a><br>
> [2] <br>
> <a href=3D"https://github.com/freebsd/freebsd-src/blob/releng/13.2/sys=
/sys/jail.h#L119" rel=3D"noreferrer" target=3D"_blank">https://github.com/f=
reebsd/freebsd-src/blob/releng/13.2/sys/sys/jail.h#L119</a><br>
> [3] <br>
> <a href=3D"https://github.com/freebsd/freebsd-src/blob/releng/13.2/sys=
/kern/kern_jail.c#L2340" rel=3D"noreferrer" target=3D"_blank">https://githu=
b.com/freebsd/freebsd-src/blob/releng/13.2/sys/kern/kern_jail.c#L2340</a><b=
r>
<br>
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.<br>
<br>
Pat<br>
<br>
[1] <a href=3D"https://github.com/freebsd/freebsd-src/blob/releng/13.2/lib/=
libc/sys/Symbol.map#L672" rel=3D"noreferrer" target=3D"_blank">https://gith=
ub.com/freebsd/freebsd-src/blob/releng/13.2/lib/libc/sys/Symbol.map#L672</a=
><br>
[2] <a href=3D"https://github.com/freebsd/freebsd-src/blob/releng/13.2/shar=
e/mk/bsd.symver.mk#L43" rel=3D"noreferrer" target=3D"_blank">https://github=
.com/freebsd/freebsd-src/blob/releng/13.2/share/mk/bsd.symver.mk#L43</a><br=
>
[3] <a href=3D"https://github.com/freebsd/freebsd-src/blob/releng/13.2/shar=
e/mk/bsd.lib.mk#L253" rel=3D"noreferrer" target=3D"_blank">https://github.c=
om/freebsd/freebsd-src/blob/releng/13.2/share/mk/bsd.lib.mk#L253</a><br>
<br>
</blockquote></div>
--0000000000007475a405ff6ce353--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrrxn6kh%2BTzkNdkQGhPPE_Zser2QaPDqHjMTO2PaUvf4A>