>>>>> On Fri, 20 Aug 2004 12:51:03 +0900, GOTO Masanori <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
