>- 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 [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]
