On 6/5/25 11:54, Warner Losh wrote:
On Thu, Jun 5, 2025 at 6:14 AM John Baldwin <j...@freebsd.org> wrote:
On 6/4/25 19:03, Kyle Evans wrote:
On 6/4/25 17:55, Gleb Smirnoff wrote:
On Wed, Jun 04, 2025 at 01:51:14AM +0000, Kyle Evans wrote:
K> The branch main has been updated by kevans:
K>
K> URL:
https://cgit.FreeBSD.org/src/commit/?id=969f6380eb66f809eed3e5c38b6021824a4cc2bf
K>
K> commit 969f6380eb66f809eed3e5c38b6021824a4cc2bf
K> Author: Kyle Evans <kev...@freebsd.org>
K> AuthorDate: 2025-06-04 01:51:06 +0000
K> Commit: Kyle Evans <kev...@freebsd.org>
K> CommitDate: 2025-06-04 01:51:06 +0000
K>
K> kdump: nicer printing of kill(2) PID argument
K>
K> Similar to wait*(), kill(2) operates on a pid that currently gets output
K> as hex. Output it in decimal to make it a little easier to eyeball the
K> pid we're signalling.
K>
K> Reviewed by: markj
K> Differential Revision: https://reviews.freebsd.org/D50508
I didn't review if PIDs are always printed as decimals or not, but for
the file descriptors it is a mix of hex and decimals. :( Usually I go
with a sed script over kdump output to make it consistent.
To be fair, I'd like to fix that, too- I noticed close() the other day
for fd > 0, but paused when I:
1.) couldn't tell where we even output close args
close is probably handled by the default case where where all of the
arguments are just output as hex values. Note that for kdump, most
syscalls fall into this case including syscalls with pointer arguments.
You'd probably be a bit sad with 64-bit pointers printed as decimal
for many system calls.
truss is different as truss stores some rudimentary type information about
system call arguments and then defaults to printing certain types like
file descriptors and ids as decimal. truss also prints NULL for null
pointers IIRC.
A useful project perhaps would be to move the table describing system
call argument types out of syscalls.c in truss and into libsysdecode so
that kdump could also reuse it. Probably the API you would want is
something that returns an individual `struct syscall_decode` given
(ABI, number) input arguments.
Yes. All this generation is why we did the lua project to make the
master system call table parsing into a library. We need it also for
qemu-bsd-user long-term: writing new system calls by hand is a pain
and error-prone.
I don't think you can generate this table automatically from makesyscalls.lua
as many of the "types" truss uses are synthetic types that aren't visible
in C, e.g. "OpenFlags" meaning O_* flags passed to open(2).
I think that we should, in the fullness of time, flag these so we can
do that. If we do add additional notations, we can not only have
better truss/trace output, as well as being able to generate the right
flag translations for running FreeBSD binaries on Linux (which people
are doing by hand right now...).
This would allow kdump's hand-written per-syscall-number rules to instead
be closer to truss where you instead just iterate over types. It would
also mean only having to update a single table in libsysdecode when adding
a new system call to add both truss and kdump support. Only when a new
argument type is added would one have to actually touch truss or kdump
directly.
I'd love for this to be generated as well... It was certainly one of
the use cases that we had in mind for the GSOC project that did this.
If we don't currently have a GSoC project idea around the above thoughts
about truss -> libsysdecode and how we might be able to leverage
makesyscalls and/or other annotations for it, maybe that'd be good to
fish for in the 2026 program. I'm afraid I don't really have time for
more than the sniping of random cases that make my life a tiny bit
harder for the foreseeable future.
Thanks,
Kyle Evans
