Re: [libunwind] comments on libunwind proposal

[Jim Wilson]

>The proposed API provides a superset of the functionality
>defined by the C++/psABI unwind interface.

If that is your intent, then the name is OK.  However, that isn't clear
from the 0.0 prototype, since nowhere does it mention any of the _Unwind_*
functions required by the C++/psABI unwind library interface.  Nor does it
refer to the C++/psABI unwind library interface anywhere either as far as
I can tell.  Hence it appears to be a different interface.

>  The
>current implementation *is* IA-64 specific, but that's just because I
>can't do everything on my own.  I'd love to see, e.g., x86 and Alpha
>implementations.

We already have them in gcc, and they are already known to work.
There is no need for you to do everything on your own if you do work on
the existing gcc code.

>As far as we could tell, the GCC IA-64 unwinder is effectively
>unmaintained.

It is actively maintained.  Unfortunately, IA-64 gcc is desperately short
of volunteers, and has been since the beginning on the Trillian project.
There seem to be many more people willing to work on the IA-64 kernel than
on IA-64 gcc, and yet the biggest problems (e.g. performance) are in gcc.

Hans Boehm has trouble because he primarily cares about Java, and Java is
our third priority after C and C++, so we don't always have time to fix the
problems that he cares most about.

If starting a new libunwind project encourages more people to work on the
unwinder and gcc, then it will be a good thing.  However, if this just
splits the effort of existing volunteers between libunwind and gcc, then
this could further delay the progress of gcc, which would be a bad thing.

Jim