On 01/22/2017 21:24, Joshua Kinard wrote: > On 01/22/2017 20:03, Joshua Kinard wrote: >> On 01/22/2017 18:28, Joshua Kinard wrote: >>> I think I've run into a really odd gcc-6.3.x miscompile bug here on IP27. >>> But I'm not sure. I've reproduced the issue on 4.9.5, 4.8.17, and now >>> 4.7.10 (which I KNOW should boot). If I recompile the same 4.7.10 kernel >>> with gcc-5.4.0, though, it boots as expected. The fault appears to be in >>> the assembly for _raw_spin_lock_irq. [snip] > I am not sure what to call this. This is definitely not happening with a > gcc-5.4.x-built kernel, so it's a code-generation issue of some kind: With some help from the gcc mailing list, the "sd" instructions emitted at the beginning of every function is from the -fstack-check flag. It enables stack-probing to ensure there is sufficient space on the stack, else it'll trigger a SEGV. My guess is for IP27, at this early point in boot, the memory system isn't up and running yet, due to IP27's somewhat-unique nature. Thus, this stack-probe will fail and trigger the NULL deref in _raw_spin_lock_irq(). The workaround I am going to go with is to add -fno-stack-check to IP27's arch/mips/sgi-ip27/Platform file to disable stack-checking. As far as I can tell, this solves the issue on IP27 by not emitted these instructions anymore (verified w/ objdump). Not sure where this flag is getting set from. Could be set in my distro's toolchain somewhere. But since at least IP30 is not affected, I am going to assume it's specific to IP27 for now. I'll send a patch in later this week... -- Joshua Kinard Gentoo/MIPS kumba@xxxxxxxxxx 6144R/F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
