On Fri, 02 Jun 2006 08:54:04 +0200
"Jan Beulich" <[email protected]> wrote:
> >- 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,
>
> The problem is that the unwind is expected to end with an odd state (i.e. fail), at least until all possible root
> points of execution (i.e. bottoms of call stacks) have a proper annotation forcing their parent program counter to zero
> (which I don't expect to happen soon, if ever, because I think this is something difficult to prove). Thus the only
> reasonable thing to do is to check whether the first level of unwinding failed.
>
Are there other heuristics we can apply? For example, we have a pretty
good idea whereabouts the top of a kernel stack is. If we don't end up
close to that offset then we can assume that something went wrong?
> > - 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.
>
> This might be a config or boot option (and might be forced on for a short while), but I generally don't think this is
> helpful, given that the entire point of the added logic is to remove (useless) information (even more that if you have
> to rely on the screen alone, you have to live with its limited size, and pushing out an old-style stack trace after the
> unwound one would likely make part or all of it as well as the register information disappear).
>
Plus a config or boot option is too late.
-
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]
