On Thu, 1 Jun 2006 09:19:27 -0700
Andrew Morton <[email protected]> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
