Re: 2.6.17-rc5-mm2

[Andrew Morton <akpm@osdl.org>]

On Thu, 01 Jun 2006 14:20:24 +0200
"Jan Beulich" <jbeulich@novell.com> wrote:

> >Jan, the dwarf2 unwinder apparently fails if we call a NULL function. 
> 
> That is expected behavior, as a NULL program counter (to the unwinder) means end-of-stack-frames.

Is it actually _expected_ that we'll encounter a NULL EIP during the unwind?

Because if it is not, then this is a good indication that the unwind
attempt hasn't worked, so we should fall back to some other approach if we
encounter a NULL at _any_ point in the backtrace, not the start.

Creating too much information is waaaaaaaaaaay better than creating too
little.  (This is a case in point - we're trying to fix a bug here and the
unwinder is preventing that).

In fact, if there's any means at all by which we can detect that something
has gone wrong with the unwind we should fall back.

> 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.