Date: Sat, 4 May 2013 17:17:13 +0100 From: Andrew Turner <andrew@fubar.geek.nz> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-arm <freebsd-arm@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 04 May 2013 09:08:19 -0600 Ian Lepore <ian@FreeBSD.org> wrote: > On Fri, 2013-05-03 at 11:51 +0100, Andrew Turner wrote: > > On Wed, 01 May 2013 14:17:32 -0600 > > Ian Lepore <ian@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130504171713.1ae33892>