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

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

Goto,

It appears the current libc (2.3.2.ds1-18) still has been copiled with
omit-frame-pointer.

If dropping omit-frame-pointer is not acceptable (for whatever reason),
please consider adding -fexceptions instead.  That way, GCC will at
least add unwind-tables, so a DWARF2-capable unwinder can work.

Is it possible to fix this before Debian 3.1 is released?  It would be
very nice, since otherwise, backtraces are hopelessly broken.

Thanks,

	--david

>>>>> On Fri, 10 Sep 2004 12:21:04 +0900, GOTO Masanori <gotom@debian.or.jp> said:

  Goto> At Fri, 20 Aug 2004 00:26:37 -0700, David Mosberger wrote:
  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> Oops.  I didn't confirm which architecture was used.  Plus I
  Goto> should know ia64 frame structure, too.

  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.

  Goto> Yes, if it makes problem, and if it does not cause
  Goto> siginificant performance drop, I think it should be modified.

  Goto> Regards, -- gotom