On Tue, Dec 19, 2017 at 11:38 PM, Vineet Gupta <vineet.gup...@synopsys.com> wrote: > On 12/19/2017 12:13 PM, Arnd Bergmann wrote: >> >> >>> I suppose BUG() implies "dead end" like semantics - which ARC was lacking >>> before ? >> >> Correct. Using __builtin_trap() here avoids the 'control reaches end of >> non-void >> function' warnings, but then makes us run into the stack size problem that >> I work around with the barrier_before_unreachable(). >> >> It would be good if you could give this a quick test to see if you get >> sensible >> output from the __builtin_trap(); > > > It does, added a BUG() arbit, hits an abort() > > ... > ISA Extn : atomic ll64 unalign (not used) > : mpy[opt 9] div_rem norm barrel-shift swap minmax swape > BPU : partial match, cache:2048, Predict Table:16384 > BUG: failure at ../arch/arc/mm/tlb.c:827/arc_mmu_init()! > > > Tested-by: Vineet Gupta <vgu...@synopsys.com>
I meant whether it prints the right registers and stack trace, but I assume you tested that and just did not list it above. > FWIW newer ARC gcc actually implements the builtin so we get a trap 5 > instruction now, vs., abort() calls before. > > BTW I missed reading the hunk of your changelog where this addresses the > long standing mystery with ARC builds and numerous -Wreturn-type warnings. I > always wondered why they were not fixed upstream already, being too lazy to > investigate myself, and turns out this was due to this BUG() thingy. phew ! Hmm, so with the new definition of abort(), +__weak void abort(void) +{ + BUG(); + + /* if that doesn't kill us, halt */ + panic("Oops failed to kill thread"); +} won't that run into an endless recursion? Or do you then override abort() for ARC? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html