[libunwind] libunwind v0.96 released

[David Mosberger]

v0.96 of libunwind has just been released.  You can get it from:

  ftp://ftp.hpl.hp.com/pub/linux-ia64/libunwind-0.96.tar.gz

Relative to v0.95, there are two main changes:

 - Support for the exception-handling interface originally defined by
   the C++ ABI group has been added.  This consists of a new header-file
   <unwind.h> and a set of routines:

        _Unwind_DeleteException()
        _Unwind_ForcedUnwind()
        _Unwind_GetGR()
        _Unwind_GetIP()
        _Unwind_GetLanguageSpecificData()
        _Unwind_GetRegionStart()
        _Unwind_RaiseException()
        _Unwind_Resume()
        _Unwind_SetGR()
        _Unwind_SetIP()

   See http://www.codesourcery.com/cxx-abi/abi-eh.html for details.
   If you define _GNU_SOURCE when compiling a program including
   <unwind.h>, you'll also get the following additional routines,
   which were added by the GCC folks:

        _Unwind_Backtrace()
        _Unwind_GetBSP()
        _Unwind_GetCFA()
        _Unwind_GetDataRelBase()
        _Unwind_GetTextRelBase()
        _Unwind_Resume_or_Rethrow()
        _Unwind_FindEnclosingFunction()

   See the header file <unwind.h> for some documentation on these.

 - A new routine called unw_get_proc_info_by_ip() has been added.
   This works exactly like unw_get_proc_info() except that instead of
   a valid cursor, you just need a valid instruction pointer.
   However, this new routine is slower (and often much slower) than
   unw_get_proc_info(), so unless you absolutely have to, it's not
   recommended to use it (the reason I had to add it was so that
   _Unwind_FindEnclosingFunction() can be implemented).

v0.96 should be fully backwards compatible to v0.95.  Furthermore,
thanks to the addition of the _Unwind_*() routines, libunwind can now
be used as plug-in replacements for other unwind libraries, such as
the libunwind.so shipped with the Intel compilers.

Oh, one subtle change: for now, I turned off per-thread caching.  The
reason I did this is because the per-thread cache consumes a fairly
large amount of thread-local storage (TLS) --- about 128KB --- even
when per-thread caching is never used.  Furthermore, I'm not really
sure per-thread-caching is worth it.  If someone has some figures to
prove otherwise, I'd be very interested in seeing them.  Anyhow, if
someone feels strongly about per-thread caching, we can try to come up
with a solution that satisfies everyone.

Enjoy,

        --david