libunwind-devel
[Top][All Lists]
Advanced

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

Re: [libunwind] Basic use of dynamic features?


From: David Mosberger
Subject: Re: [libunwind] Basic use of dynamic features?
Date: Thu, 16 Dec 2004 11:31:36 -0800

>>>>> On Thu, 16 Dec 2004 11:26:19 +0100, Tommy Hoffner <address@hidden> said:

  Tommy> David Mosberger wrote:
  >>>>>>> On Tue, 14 Dec 2004 17:15:23 +0100, Tommy Hoffner
  >>  <address@hidden> said:

  Tommy> Ok, I tried 0.98.3 from debian. Now the UNW_LOCAL_ONLY
  Tommy> doesn't work either :-)
  >>  It's good you mentioned Debian!  Your problem is due to a Debian
  >> packaging issue: /usr/lib/libunwind.so.7 is currently being
  >> provided by the libunwind from GCC-3.4, which doesn't support
  >> dynamic unwinding at all.

  Tommy> Hm, I looked around the debian packages, lets see if I got
  Tommy> it.  /lib/libunwind.so.7 is provided by the libgcc package (I
  Tommy> assume this is what you mean by "from GCC 3.4"), the
  Tommy> libunwind7 package only provides platformspecific support
  Tommy> (i.e. /usr/lib/libunwind-ia64.s0.7) but no support for
  Tommy> dynamic unwindinding.  The libunwind7-dev packages contains
  Tommy> libunwind.a which does support dynamic unwinding (in the
  Tommy> sence that it contains _U_dyn_register) but since there is no
  Tommy> way of telling gcc-3.4 not to use /lib/libunwind.so.7 (i.e
  Tommy> only link with libunwind.a), the extra functionality in that
  Tommy> library is broken.

  Tommy> So the only way to get support for dynamic unwinding right
  Tommy> now is to force gcc (i.e. libgcc?) to use another
  Tommy> libunwind.so.7 that supports both gcc's "internal" needs as
  Tommy> well as mine?

That's basically correct.

For the time being, libunwind.so.7 definitely will be provided by the
libgcc package.  This is due to the late stage that Debian/sarge is
in---otherwise, the natural thing to do would have been to say "libgcc
package depends on libunwind package".

The GCC maintainer agreed to see if he can build the libunwind.so.7
from my libunwind sources (instead of the GCC-3.4 sources).  If that
happens, all the confusion would go away: /lib/libunwind.so.7 will
provide all you need.

  >> $ g++-3.4 -L/tmp/u/src/.libs jitunw.C flush-cache.s -lunwind -o
  >> jitunw $ LD_LIBRARY_PATH=/tmp/u/src/.libs jitunw pagesize 16384
  >> SUCCESS! (Caught Throw)

  Tommy> Ok, works for me as well.

Great!

  >>  Of course, the other option is to install the libunwind from the
  >> package.  The only caveat is that you need to make sure it gets

  Tommy> I'm not sure understand. The only package I found that
  Tommy> contains libunwind.so.7 is libgcc1, and that is the crippled
  Tommy> one.

Yes.  Hopefully, libgcc1 will rev soon such that you won't get a
crippled libunwind anymore.

  Tommy> If you mean installing one I build myself from source, then
  Tommy> ok, that will work.

For the time being, that's the only choice.

  >> installed in /lib (with a symlink to /usr/lib).  I'll see about
  >> making this the default.

  Tommy> I was hoping to use debian packages to setup as much as
  Tommy> possible of our environment.

I hope it's just a matter of a few more days.  The goal is definitely
to get this sorted out ASAP.

The good news is that things are starting to look real good.  For
example, with the forthcoming gcc & glibc Debian packages installed
the libunwind "make check" succeeds on _all_ tests on ia64!

        --david

reply via email to

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