On Sat, Oct 14, 2017 at 6:57 AM, Krzysztof Strzeszewski <krz...@krzy.ch> wrote:
> This is very interested "the kernel did non panic". panic() is an explicit call in the kernel, made when some sanity or consistency check fails. Dereferencing a bogus pointer results in a failed page fault trap and goes to ddb directly without going through panic(), so there's no "panic message". (Someone looking for a kernel change to hack on? How about this: figure out how to make ddb's "show panic" report something useful when you entered ddb via a kernel page fault where uvm_fault() returned EFAULT.) > Where is memcmp in sys? When I run bsd.rd end mount filesystem I can't > find memcmp. > memcmp() is a function inside the kernel, so I'm not sure what your last statement means. ... > ddb> trace > memcmp(d3182800,681,9,1b) at memcmp+0x11 > k7_powernow_init(d31810c0,d0ec2f08,d022931e,d0c70730,d0a217fd) at > k7_powernow_init+0xf8 > amd_family6_setperf_setup(d0c70730) at amd_family6_setperf_setup+0x1c > mainbus_attach(0,d31810c0,0) at mainbus_attach+0x15e > ... This trace is kinda weird: k7_powernow_init+0xf8 matches with it being a call to k7pnow_states(), which does calls memcmp(), but where did the intermediate stack frame go? And why are the args to memcmp() so odd? On top of it, nothing has really changed in the K7 code since 6.1, so the only real change is the change in compilers from gcc to clang. The resulting object code is _substantially_ different: that clang doesn't inline the memcmp() call is just one aspect. Is there something in that code which clang is deciding to optimize in ways that break it? Philip Guenther
