lkml.org 
[lkml]   [2006]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2006-06-02 08:55    [W:0.020 / U:61.088 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site