From owner-freebsd-arm@FreeBSD.ORG Sat May 4 16:17:17 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0F2352D4; Sat, 4 May 2013 16:17:17 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id E936B264; Sat, 4 May 2013 16:17:16 +0000 (UTC) Received: from bender (cpc24-aztw24-2-0-cust99.18-1.cable.virginmedia.com [92.237.65.100]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 7962E5E1F5; Sat, 4 May 2013 16:17:15 +0000 (UTC) Date: Sat, 4 May 2013 17:17:13 +0100 From: Andrew Turner To: Ian Lepore Subject: Re: A fix for the clang + eabi + kdb backtrace endless loop Message-ID: <20130504171713.1ae33892@bender> In-Reply-To: <1367680099.1180.162.camel@revolution.hippie.lan> References: <1367439452.1180.92.camel@revolution.hippie.lan> <20130503115141.6c9cd15a@bender> <1367680099.1180.162.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 16:17:17 -0000 On Sat, 04 May 2013 09:08:19 -0600 Ian Lepore wrote: > On Fri, 2013-05-03 at 11:51 +0100, Andrew Turner wrote: > > On Wed, 01 May 2013 14:17:32 -0600 > > Ian Lepore wrote: > > > > > The attached patch fixes the problem where a kdb backtrace loops > > > endlessly on an eabi kernel. > > > > > > I'm no expert on this stuff, so while this fixes the problem for > > > me, I'm not sure it's right, especially the STOP_UNWINDING in > > > exception_exit (which handles a test case of breaking into the > > > debugger with the keyboard and typing 'bt'). I'm not going to > > > commit this until it's been reviewed by someone who actually > > > knows what they're doing. :) > > STOP_UNWINDING tells binutils to generate the required unwind > > op-code to tell the kernel's unwinder it needs to stop in this > > function. There is a bug with the unwinder where it should tell the > > user it is in the function, however it doesn't currently. > > > > See below for more comments. > > Thanks for the review and info. I didn't realize FP was unused in > EABI. I guess keying off it just accidentally worked right in the few > cases I tested. > > I was also a bit worried about the recursion case with using the PC to > see if unwinding seemed to be stuck. I studied the code some more and > discovered that there's a mask of which registers changed, used for > pretty-printing. I think that's a safer way to determine whether > unwinding is stuck in a loop -- if no registers changed then nothing > was unwound. > > I also restructured things a bit so that the decision to stop > unwinding isn't acted on until after the current frame is printed; > that seems to ensure that the frame for a STOP_UNWINDING function > gets printed before exiting the loop. > > So, here's a somewhat more clueful patch; how's this look? > > -- Ian > The updated db_trace.c looks good, however I am currently unable to test the change. In exception.S you added the following comment: For EABI, don't try to unwind any further than this, because the unwind info generated here is a single INSN_FINISH instruction. Nothing gets unwound (no registers change) so the unwind would loop here forever. It's not quite correct. Registers are loaded in PULLFRAMEFROMSVCANDEXIT however we don't yet record this fact in the macro. I would suggest something like: For EABI, don't try to unwind any further than this, because the unwind info generated here is a single INSN_FINISH instruction. This is because, while PULLFRAMEFROMSVCANDEXIT modifies registers, we don't store these changes in the unwind table. Any other asm functions that shouldn't be unwound past can have STOP_UNWINDING added to them. For other ASM functions we need to start telling the unwinder about the register changes, allowing this is on my TODO list but I haven't had a chance to look into it yet. Andrew