Reminds me about one time when I've spent a week debugging random, but quite consistent kernel crashes, which turned out to be a gcc miscompiling kernel driver code to decrement stack pointer before ceasing to use some values in that stack area. There was one or two instructions, where if a re-entrant irq happened, would reuse that stack part and corrupt data there.
> To reproduce, build the attached program with "gcc -pthread test.c" and run it on a 5.2 or later kernel compiled with GCC 9 (if the kernel is compiled with GCC 8, it does not reproduce).
I wonder if this is a compiler bug or a new optimization that broke the code.
From the link, it seems like GCC 8 does not cache a read from a variable, and has more memory access to read it, while GCC 9 reads that variable from a register every time. (Maybe from a corrupted register?)
Probably a mix of both; when developing a kernel, you constantly fight against the compiler trying to be smart and optiziming things out of your code, inlining things, caching data, etc.
In this case, it might be necessary to do a volatile read in case that flag has changed, forcing the compiler to reload it.
[+] [-] KindOne|6 years ago|reply
"Debugging an evil Go runtime bug" - https://news.ycombinator.com/item?id=15845118
https://github.com/golang/go/issues/20427
https://bugs.gentoo.org/637152
https://lkml.org/lkml/2017/11/10/188
[+] [-] jameskilton|6 years ago|reply
[+] [-] ronsor|6 years ago|reply
[+] [-] dpc_pw|6 years ago|reply
[+] [-] Vogtinator|6 years ago|reply
[+] [-] saagarjha|6 years ago|reply
I wonder if this is a compiler bug or a new optimization that broke the code.
[+] [-] asveikau|6 years ago|reply
[+] [-] zaarn|6 years ago|reply
In this case, it might be necessary to do a volatile read in case that flag has changed, forcing the compiler to reload it.
[+] [-] kakkoko|6 years ago|reply