[Top][All Lists]
[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"