[Top][All Lists]

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

[libunwind] comments on libunwind proposal

From: Jim Wilson
Subject: [libunwind] comments on libunwind proposal
Date: Mon, 14 Jan 2002 21:32:56 -0800

The terminology is confusing.  The C++ ABI and IA-64 psABI both define
an Unwind Library interface.  I have never heard the term "unwind API"
used to refer to anything but that, but now you are using it for something
else.  The Unwind API defined by the C++ ABI and IA-64 psABI is a high
level interface designed to be called by a C++ language front end.  It
contains functions like _Unwind_RaiseException and _Unwind_Resume.  What
you have implemented is a low level library that is intended to read
IA-64 unwind info sections, and use this info for stack unwinding.  In
gcc, we call this the IA-64 (stack) unwinder.

Gcc incidentally already uses the (C++ ABI) Unwind API for all targets.
But that is irrelevant, since you aren't implementing the Unwind API.
Beneath the Unwind API, we have 3 different unwinders, the setjmp/longjmp
unwinder, the dwarf2 unwinder, and the IA-64 unwinder.  The last one is
comparable to what you are implementing.  A generic unwinder library will
be more useful if it supports all unwind info formats, and not just the
IA-64 unwind info format.

Your current implementation looks like you just took the kernel unwinder
you wrote and made it into a library.  The current gcc IA-64 unwinder is
based on your kernel unwinder, with modifications and additions necessaary
to make it work with the Unwind API.  I think it would be worthwhile for
you to look the gcc implementation.  Incidentally, the hardest part of
the gcc implmentation was restoring an old stack state sufficiently to resume
execution using it.  This is something that your current kernel unwinder
does not support.  Since we already have the code in gcc, it may not be
worth the effort of writing another one.  The gcc one is about 200 lines
of IA-64 assembly code.  The gcc IA-64 unwinder incidentally has already
been extensively tested.  Richard Henderson did most of the work for the
current gcc IA-64 unwinder implementation.

Putting the unwinder library in glibc is problematic, since glibc does not
exist everywhere we need it.  Gcc still needs the unwinder, even when we
compile it on HPUX, BSD, and other non-linux operating systems that do not
use glibc.  It would be useful to have an IA-64 unwinder outside gcc so
that gdb can use it too; it just doesn't work to put it in glibc.

Your current unwinder implementation defines routines like "unw_get_reg".
Making these routines available to the user means exporting them, and
that means we have conflicts with the user namespace.  You may want to
consider using names outside the user namespace, like the Unwind API does.
These functions will be present in most applications since the IA-64 unwinder
gets pulled into almost everything by the compiler.  The user can't avoid name
space clashes by choosing not to use the IA-64 unwinder library, so we are
better off if these function names aren't in the user namespace to begin with.


reply via email to

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