Re: git: 969f6380eb66 - main - kdump: nicer printing of kill(2) PID argument

On 6/5/25 11:54, Warner Losh wrote:
> On Thu, Jun 5, 2025 at 6:14 AM John Baldwin <jhb@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 <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 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