1. 11 10月, 2007 1 次提交
  2. 26 9月, 2006 2 次提交
    • J
      [PATCH] i386/x86-64: Work around gcc bug with noreturn functions in unwinder · adf14236
      Jan Beulich 提交于
      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: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      adf14236
    • A
      [PATCH] x86: Detect CFI support in the assembler at runtime · e2414910
      Andi Kleen 提交于
      ... 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: NAndi Kleen <ak@suse.de>
      e2414910
  3. 26 4月, 2006 1 次提交
  4. 12 1月, 2006 2 次提交
  5. 13 9月, 2005 1 次提交
  6. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4