libunwind-devel
[Top][All Lists]
Advanced

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

Re: [libunwind] libunwind v0.97 released


From: Matthieu Delahaye
Subject: Re: [libunwind] libunwind v0.97 released
Date: Fri, 7 May 2004 15:16:20 +0200
User-agent: Mutt/1.5.5.1+cvs20040105i

On Thu, May 06, 2004 at 05:57:35PM -0700, David Mosberger wrote:
> v0.97 of libunwind has just been released.  You can get it from:
[snip]
> 
> 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).
[snip]

After building libunwind 0.97, libunwind-generic.so and
libunwind-generic.a a respectively symbolic links to libunwind-ia64.so
and libunwind-ia64.a

In other words, it assumes libunwind-generic is libunwind-PLAT for the
host platform.

My configure options are:
./configure ./configure --host=$(DEB_HOST_GNU_TYPE) 
--build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=\$${prefix}/share/man 
--infodir=\$${prefix}/share/info

with DEB_HOST_GNU_TYPE = ia64-linux
     DEB_BUILD_GNU_TYPE = ia64-linux

Using simple ./configure give the same result.

Is that the expected result?

Matthieu

> 
> 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.
> _______________________________________________
> libunwind mailing list
> address@hidden
> http://www.hpl.hp.com/hosted/linux/mail-archives/libunwind/

-- 
It were not best that we should all think alike; it is difference of opinion
that makes horse-races.
                -- Mark Twain, "Pudd'nhead Wilson's Calendar"


reply via email to

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