Date: Thu, 5 Jun 2025 11:12:45 -0700 From: Warner Losh <imp@bsdimp.com> To: Kyle Evans <kevans@freebsd.org> Cc: John Baldwin <jhb@freebsd.org>, Gleb Smirnoff <glebius@freebsd.org>, markj@freebsd.org, src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 969f6380eb66 - main - kdump: nicer printing of kill(2) PID argument Message-ID: <CANCZdfq9X6GR91CXAAN%2B0BrmZ=GXeEX36m6t9ScwUPGLC=Wrww@mail.gmail.com> In-Reply-To: <701efeb3-3a7e-42fe-ba18-eaf1862c7a3f@FreeBSD.org> References: <202506040151.5541pESm016476@gitrepo.freebsd.org> <aEDO_3cfSbx2JnCG@cell.glebi.us> <02ed6d30-b22a-456d-96e2-7f5b235766fd@FreeBSD.org> <0b4a1945-8f75-4f57-9a57-5bd0c10a7af1@FreeBSD.org> <CANCZdfoCU=t=s2g5u7Ng_9jpdvXA8BMLCv4Dw0HNeTKn1GbVCg@mail.gmail.com> <701efeb3-3a7e-42fe-ba18-eaf1862c7a3f@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 5, 2025 at 10:59=E2=80=AFAM Kyle Evans <kevans@freebsd.org> wro= te: > > On 6/5/25 11:54, Warner Losh wrote: > > On Thu, Jun 5, 2025 at 6:14=E2=80=AFAM John Baldwin <jhb@freebsd.org> w= rote: > >> > >> 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=3D969f6380eb66f809ee= d3e5c38b6021824a4cc2bf > >>>> K> > >>>> K> commit 969f6380eb66f809eed3e5c38b6021824a4cc2bf > >>>> K> Author: Kyle Evans <kevans@FreeBSD.org> > >>>> K> AuthorDate: 2025-06-04 01:51:06 +0000 > >>>> K> Commit: Kyle Evans <kevans@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 e= yeball 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 f= or > >>>> 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 da= y > >>> 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 a= bout > >> 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 s= o > >> 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 makesysca= lls.lua > >> as many of the "types" truss uses are synthetic types that aren't visi= ble > >> 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 inst= ead > >> be closer to truss where you instead just iterate over types. It woul= d > >> also mean only having to update a single table in libsysdecode when ad= ding > >> a new system call to add both truss and kdump support. Only when a ne= w > >> 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. That's a great idea. I've not had the time to write it up with sufficient detail for a gSOC student to want to do it... There's half a dozen different projects we could do to improve somebody's quality of life and implementation... Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfq9X6GR91CXAAN%2B0BrmZ=GXeEX36m6t9ScwUPGLC=Wrww>