From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vineet.Gupta1@synopsys.com (Vineet Gupta) Date: Wed, 20 Dec 2017 12:29:02 -0800 Subject: [PATCH] bug.h: Work around GCC PR82365 in BUG() In-Reply-To: References: <20171219114112.939391-1-arnd@arndb.de> <8e42a1de-f619-7a4e-6d58-f90f53f5f38f@synopsys.com> <27bfdc23-1774-cf07-dab4-ab253a41d2f7@synopsys.com> List-ID: Message-ID: <861992dd-a28d-0f8c-572f-4194d15238df@synopsys.com> To: linux-snps-arc@lists.infradead.org On 12/20/2017 12:12 PM, Arnd Bergmann wrote: >> Sorry, I didn't realize we are missing the stack trace now which you removed >> from the patch - why ? Did u intend to reduce inline generated code for the >> stack dump calls - which sounds like a great idea. But it would only work >> for the synchronous abort() but not when builtin translates to actual trap >> inducing instruction. > > I assumed that the trap instruction would trigger the register and > stack dump, as it does on all other architectures. Only if __builtin_trap() translated to that instruction. Otherwise we need to do this inside abort() > The most common > way this is handled is to have one instruction that is known to trap, > and use that to trigger a BUG(), and have __builtin_trap() issue > that instruction as well. Good point. So we'll need ARC specific abort anyways. > You might also want to implement CONFIG_DEBUG_BUGVERBOSE > support to attach further data to it. OK I'll take a look ! > How about overriding abort() with the same instruction that > __builtin_trap() inserts on newer compilers then? That should > make the behavior consistent. Yeah this is a great point ! Will do thx, -Vineet