Re: TLS-version of libc6/{testing,unstable} breaks libunwind

[David Mosberger <davidm@napali.hpl.hp.com>]

>>>>> On Fri, 20 Aug 2004 12:51:03 +0900, GOTO Masanori <gotom@debian.or.jp> said:

  GOTO> Hi David, At Thu, 19 Aug 2004 04:36:59 -0700, David Mosberger
  GOTO> wrote:
  >> I recently noticed that with Debian/testing or Debian/unstable,
  >> many libunwind [1] checks are failing with a SEGFAULT.  The
  >> root-cause of these crashes appears to be that the TLS-version of
  >> libc-2.3.2 is built with -fomit-frame-pointer on i386 (see
  >> nptl_extra_cflags in debian/sysdeps/i386.mk of the package).  It
  >> would be OK to use -fomit-frame-pointer if the library provided
  >> DWARF2 unwind-info for all functions compiled in this manner.
  >> However, for some reason, the unwind-info for __libc_start_main
  >> is not present in the library.  Specifically:
  >> 
  >> $ nm -D /lib/tls/libc-2.3.2.so | grep __libc_start_main 000156f0
  >> T __libc_start_main $ readelf -wf /lib/tls/libc-2.3.2.so |head
  >> -17 The section .eh_frame contains:
  >> 
  >> 00000000 00000014 00000000 CIE Version: 1 Augmentation: "zR" Code
  >> alignment factor: 1 Data alignment factor: -4 Return address
  >> column: 8 Augmentation data: 1b
  >> 
  >> DW_CFA_def_cfa: r4 ofs 4 DW_CFA_offset: r8 at cfa-4 DW_CFA_nop
  >> DW_CFA_nop
  >> 
  >> 00000018 00000018 0000001c FDE cie=00000000 pc=00015b10..00015bb9
  >> DW_CFA_advance_loc: 3 to 00015b13
  >> 
  >> That is, even though unwind info is present in general, the first
  >> function for which there is unwind-info starts at address
  >> 0x15b10.  There is no unwind-info for __libc_start_main.
  >> 
  >> Because of this, it is _impossible_ to unwind safely through the
  >> call stack.  What happens in the case of the failing libunwind
  >> checks is that once unwinding hits __libc_start_main, libunwind
  >> starts accessing "random" memory, because __libc_start_main
  >> doesn't maintain the frame-chain yet it also doesn't provide
  >> unwind info.
  >> 
  >> The problem doesn't show with LD_ASSUME_KERNEL set to 2.4.18
  >> (i.e., when /lib/libc-2.3.2.so is in use).  Also, I checked on a
  >> Red Hat Enterprise Linux AS release 3 machine and it doesn't show
  >> the problem either.  It also uses TLS-enalbed libc-2.3.2, but I
  >> suspect it was built without -fomit-frame-pointer.

  GOTO> I prepared 2.3.2.ds1-16_ia64 compiling without
  GOTO> -fomit-frame-pointer.  It's added by debian/sysdeps/linux.mk.
  GOTO> I put that version at:

  GOTO> 	http://www.gotom.jp/~gotom/debian/debian/glibc/2.3.2.ds1-16_ia64.fofp/

  GOTO> David, could you check it?  Unfortunatelly I have no
  GOTO> permission to access chroot on ia64 to test this kind of
  GOTO> problems.

Thanks, but why ia64?  My bug-report was for i386.  There is no issue
for ia64 (where omit-frame-pointer is a no-op).

  GOTO> I think it's good idea to drop -fomit-frame-pointer from
  GOTO> linux.mk for building libc with NPTL.  If such optimization
  GOTO> option is fine for specific architecture, it should be defined
  GOTO> -fomit-frame-pointer in debian/sysdeps/*.mk.

Does this mean you plan on rebuilding the i386 glibc without
-fomit-frame-pointer?  That would be fine with me.

Thanks,

	--david