Date: Sat, 7 Mar 2020 21:42:29 -0800 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: bugzilla 213937, syscall(int, ...), struct ktr_syscall's short ktr_code, struct syscall_args's u_int code: should the bug be closed? Message-ID: <5AEC7760-EF38-4738-AEBD-9E563CB0E62B@yahoo.com> References: <5AEC7760-EF38-4738-AEBD-9E563CB0E62B.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Question: Should bugzilla 213937 be left as-is to suggest changing things so that more bad syscall "code/number" values are preserved and reported correctly if/when they happen? Background leading to the question . . . I've been reviewing some of my old bugzilla reports that are still in the new state, closing or adding notes to a bunch of them. The status for what contributes to bugzilla 213937 has not changed over the years since the submittal. Bugzilla 213937 was a report of ktrace misreporting the 24 bit field value in the armv7 svclt instruction. (I had a bad file that had such an instruction with a large 24-bit field value that lead to seeing the problems. It was rather confusing until I figured out the information reported was incorrect relative to the instruction encoding.) Part of the problem was that it looked like the lower 16 bits had been used but sign extended to produce the reported value, a negative number as reported. (It took a while to notice that.) Oleksandr Tymoshenko eventually reported in comment #2 that there is the odd mix of types in use overall (I'm using the "code" terminology below): syscall(int code,...) struct ktr_syscall's short ktr_code struct syscall_args's u_int code Sure enough, using ktr_code could generate a sign-extension of a 16-bit value. But syscall and syscall_args are a little odd as well (signed vs. unsigned at least). It looks like "short ktr_code" has been around for long before I ever ran into it and might well be expected by folks with more historical background than I had. But it can not preserve all int or u_int values for FreeBSD's normal definitions of those types. Is this something that should be fixed? Does it have a reason for being as it is? === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5AEC7760-EF38-4738-AEBD-9E563CB0E62B>