Messages in this thread | | | Date | Fri, 02 Jun 2006 08:54:04 +0200 | From | "Jan Beulich" <> | Subject | Re: 2.6.17-rc5-mm2 |
| |
>- 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.
> - 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).
Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |