26 Sep, 2006

2 commits

  • Current gcc generates calls not jumps to noreturn functions. When that happens the
    return address can point to the next function, which confuses the unwinder.

    This patch works around it by marking asynchronous exception
    frames in contrast normal call frames in the unwind information. Then teach
    the unwinder to decode this.

    For normal call frames the unwinder now subtracts one from the address which avoids
    this problem. The standard libgcc unwinder uses the same trick.

    It doesn't include adjustment of the printed address (i.e. for the original
    example, it'd still be kernel_math_error+0 that gets displayed, but the
    unwinder wouldn't get confused anymore.

    This only works with binutils 2.6.17+ and some versions of H.J.Lu's 2.6.16
    unfortunately because earlier binutils don't support .cfi_signal_frame

    [AK: added automatic detection of the new binutils and wrote description]

    Signed-off-by: Jan Beulich
    Signed-off-by: Andi Kleen

    Jan Beulich
     
  • ... instead of using a CONFIG option. The config option still controls
    if the resulting executable actually has unwind information.

    This is useful to prevent compilation errors when users select
    CONFIG_STACK_UNWIND on old binutils and also allows to use
    CFI in the future for non kernel debugging applications.

    Cc: jbeulich@novell.com
    Cc: sam@ravnborg.org

    Signed-off-by: Andi Kleen

    Andi Kleen
     

26 Apr, 2006

1 commit


12 Jan, 2006

2 commits


13 Sep, 2005

1 commit

  • Being the foundation for reliable stack unwinding, this fixes CFI unwind
    annotations in many low-level x86_64 routines, plus a config option
    (available to all architectures, and also present in the previously sent
    patch adding such annotations to i386 code) to enable them separatly
    rather than only along with adding full debug information.

    Signed-off-by: Jan Beulich
    Signed-off-by: Andi Kleen
    Signed-off-by: Linus Torvalds

    Jan Beulich
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds