On Wed, Oct 19, 2022 at 5:02 PM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote:
>
> Given I've started with cleaning up one driver already, I'll keep my eye
> on further breakage.
I wonder if we could just check for code generation differences some way.
I tested a couple of files, and was able to find differences, eg
# kernel/sched/core.c:8861: pr_info("task:%-15.15s state:%c",
p->comm, task_state_to_char(p));
- movzbl state_char.149(%rax), %edx # state_char[_60], state_char[_60]
+ movsbl state_char.149(%rax), %edx # state_char[_60], state_char[_60]
call _printk #
because the 'char' for the '%c' is passed as an integer. And the
tracing code has the
.is_signed = is_signed_type(_type)
initializers, which obviously change when the type is 'char'.
But I also checked a number of other files that didn't have that
pattern at all, and there was zero code generation difference, even
when the "readable asm" output itself had some changes in some of the
internal label names.
That was what my old 'sparse' trial thing was actually *hoping* (but
failed) to do, ie notice when the signedness of a char actually
affects code generation. And it does in fact seem fairly rare.
Having some scripting automation that just notices "this changes code
generation in function X" might actually be interesting, and judging
by my quick tests might not be *too* verbose.
Linus
