[libunwind] libunwind v0.97 released

[David Mosberger]

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

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

A summary of changes since v0.96 can be found below (and also
in the NEWS file in the top-level directory of libunwind).

The main change clearly is that libunwind has been split into two
separate libraries: libunwind.so (for local unwinding only) and
libunwind-generic.so (for generic unwinding).  For the most part, this
change should be transparent, but see the "News for v0.97" below for
details.  The main advantage of having a separate libunwind.so is that
this library is optimized for quick load time and for compatibility
with the C++ ABI (give or take, but the important thing is that it is
plugin-compatible with the libunwind.so that comes with the Intel
compiler).

For now, libunwind continues to be intended primarily for ia64 linux.
It has been tested fairly well both with GCC and the Intel compiler
(ICC v8.0, mostly).  I'm rather happy with how things work with the
Intel compiler.  It passes now the exact same tests as GCC and
produces significantly faster code.

On HP-UX and x86, this release should work no worse than before.
There is a DWARF2/3 unwinder for x86, but it's known to have some
problems.  I'm waiting here for Max's x86-64 improvements since on
that platform, libunwind is much more important and actually easier to
test (the x86 frame-chain can hide a lot of errors).

Enjoy,

        --david

--------------------------------------------------------------------
* News for v0.97:

** unw_get_proc_name() may now be called from signal-handler.

** The ptrace-helper routines are now declared in libunwind-ptrace.h.
   Applications which use ptrace-based unwinding should include
   <libunwind-ptrace.h> to get the _UPT_*() routines declared.

** libunwind has been split into a "local-only" and a "generic" versions.
   The former is optimized for local unwinding (within a process) and
   is called libunwind.so (shared version) or libunwind.a (archive
   version).  The generic version is not limited to unwinding within a
   process and is called libunwind-generic.so (shared version)
   libunwind-generic.a (archive version).  Similarly, the ptrace()
   support has been separated out into a convenience library called
   libunwind-ptrace.a.  For the most part, backwards-compatibility
   is retained.  However, when building an application which uses
   libunwind, it may be necessary to change the linker command-line
   as shown in the table below:

    Application which does: Before v0.97:  With v0.97:
    ----------------------- -------------  -----------
    local unwinding only:   -lunwind       -lunwind
    remote unwinding:       -lunwind       -lunwind-generic
    cross unwinding:        -lunwind-PLAT  -lunwind-PLAT
    ptrace-based unwinding: -lunwind       -lunwind-ptrace -lunwind-generic

   The motivation for this splitting is to keep libunwind.so as minimal
   as possible.  This library will eventually be loaded by most (if not
   all) executables and hence it is important to ensure that it can
   be loaded as quickly as possible.

** unw_getcontext() tuned on IA-64.

   The unw_getcontext() routine used to be provided by (GNU) libc
   (getcontext()).  This caused unnecessary overhead (e.g., an
   unnecessary system-call to sigprocmask()).  The new
   unw_getcontext() only does the work really needed for libunwind and
   hence performs much better.  However, this change implies that
   programs linked against libunwind v0.97 won't be
   backwards-compatible with earlier versions (there would be an
   unresolved symbol for _Uia64_getcontext()).

** Fix NaT-bit handling on IA-64.

   New test-cases have been added to test the handling of the NaT bit
   (and floating-point NaT values) and all discovered/known bugs have
   been fixed.

** Initial DWARF-based unwinder for x86.

   There is a beginning for a DWARF-based unwinder for x86.  Work for
   x86-64-support based on this DWARF unwinder is currently underway
   at IBM and it is expected that this support will be merged into the
   official tree soon.