Re: 2.6.17-rc5-mm2

[Andrew Morton <akpm@osdl.org>]

On Thu, 1 Jun 2006 09:19:27 -0700
Andrew Morton <akpm@osdl.org> wrote:

> > It can't do anything
> > in that case, so the only solution I see is to either
> > - not at all call the unwinder from trap.c if the instruction pointer before the first unwind is not within kernel
> > space, or
> > - force fall-through to the old logic if the first unwind attempt didn't yield a change to either rIP or rSP (implying
> > that in that case there was no unwind information found to start with).
> > 
> > What do you think?
> 
> - Make the code robust and able to detect "unexpected" states at all
>   points through the process.  If at the end of the process we see that we
>   have encountered an unexpected state,
> 
>   - emit a diagnostic so Jan can work out if there's a way to improve
>     the unwinder in this situation
> 
>   - do a traditional backtrace as well.

Let me just agree with myself here.  It would be wildly unacceptable for
the unwinder to cause us to get _less_ information than we presently do
under any circumstances, please.  That would be a really bad impediment to
kernel development.