Messages in this thread |  | | From | Arnd Bergmann <> | Date | Wed, 20 Dec 2017 10:01:27 +0100 | Subject | Re: [PATCH] bug.h: Work around GCC PR82365 in BUG() |
| |
On Tue, Dec 19, 2017 at 11:38 PM, Vineet Gupta <Vineet.Gupta1@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 <vgupta@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
|  |