libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] SIGFPE and _Unwind_GetIPInfo problem on x86_64 (g+


From: Lassi Tuura
Subject: Re: [Libunwind-devel] SIGFPE and _Unwind_GetIPInfo problem on x86_64 (g++-4.5)
Date: Mon, 7 Feb 2011 08:42:22 +0100

Hi,

> Interestingly, on another system with a debian-5.0-x86_64/g++-4.3, I had to 
> adjust the counter to 3, too. But libunwind keeps failing: [...]

libunwind/x86-64 detects signal frames using a marker in the dwarf unwind info: 
letter "S" in what is called the augmentation string. If the marker is missing 
in that GLIBC version, signal frames won't be detected at all. Otherwise 
there's a bug somewhere.

Something like this on RHEL5; there's a similar entry in libpthread.

$ readelf -Wwf /lib64/libc.so.6 | grep -B2 -A20 zRS
00002080 00000014 00000000 CIE
  Version:               1
  Augmentation:          "zRS"
  Code alignment factor: 1
  Data alignment factor: -8
  Return address column: 16
  Augmentation data:     1b

  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop

00002098 0000007c 0000001c FDE cie=00002080 pc=000302cf..000302d9
  DW_CFA_def_cfa_expression (DW_OP_breg7: 160; DW_OP_deref)
  DW_CFA_expression: r8 (DW_OP_breg7: 40)
  DW_CFA_expression: r9 (DW_OP_breg7: 48)
  DW_CFA_expression: r10 (DW_OP_breg7: 56)
  DW_CFA_expression: r11 (DW_OP_breg7: 64)
  DW_CFA_expression: r12 (DW_OP_breg7: 72)
  DW_CFA_expression: r13 (DW_OP_breg7: 80)

$ objdump -d /lib64/libc.so.6 | grep -A3 '^[0-9a-f]*302d0 '
00000000000302d0 <__restore_rt>:
   302d0:       48 c7 c0 0f 00 00 00    mov    $0xf,%rax
   302d7:       0f 05                   syscall 
   302d9:       0f 1f 80 00 00 00 00    nopl   0x0(%rax)

> @Lassi: Just out of curiosity, did you forget to enable exception unwinding 
> support in libunwind (--enable-cxx-exceptions)?

Why do you ask? Is that necessary for the test? FWIW, libunwind build I used 
doesn't enable that option.

> I'm just experimenting with that code, because I somehow like the idea of 
> throwing exceptions for kernel generated signals in c++. But that's surely a 
> matter of opinion :)

As you wish - at least you won't suffer boredom :-)

Regards,
Lassi


reply via email to

[Prev in Thread] Current Thread [Next in Thread]