bin/57918: kdump ioctl decoder doesn't understand sign extension

[campbell+netbsd%mumble.net@localhost]

>Number:         57918
>Category:       bin
>Synopsis:       kdump ioctl decoder doesn't understand sign extension
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Feb 09 22:00:00 +0000 2024
>Originator:     Taylor R Campbell
>Release:        current
>Organization:
The NetBSkdump Foundation
>Environment:
LP64
>Description:
When kdump(8) tries to decode ioctls nicely with _IOW(...), it incorrectly interprets a `negative' input (i.e., a bunch of leading zeros), leading it to print an _IOW(...) that doesn't produce the same result:

kdump:
 21174  21174 fido2-cred CALL  ioctl(4,_IOW('h',0x2,0x4),0x7f7fff1d8d1c)
kdump -n:
 21174  21174 fido2-cred CALL  ioctl(4,0xffffffff80046802,0x7f7fff1d8d1c)

Note that the true value of _IOW('h',0x2,0x4) is also spelled USB_HID_SET_RAW, but isn't sign-extended from 32-bit to 64-bit:

kdump:
 13581  13581 fido2-cred CALL  ioctl(4,USB_HID_SET_RAW,0x7f7fff228c0c)
kdump -n:
 13581  13581 fido2-cred CALL  ioctl(4,0x80046802,0x7f7fff228c0c)

>How-To-Repeat:
ktrace a program that does ioctl(fd, (int)USB_HID_SET_RAW, ...), kdump the result, get confused why _IOW('h',0x2,0x4) is not being decoded as USB_HID_SET_RAW
>Fix:
Yes, please!