> Is this the David Mosberger libunwind that you are referring to? Yes, it is.
> As far as I know, the actual HP libunwind only supports HPUX. The one David > Mosberger wrote is different from the HP libunwind implementation, and > is free software that supports linux. It is called libunwind and comes from HP, so HP's libunwind is probably not too much of a misnome.r:-) http://www.hpl.hp.com/research/linux/libunwind. > Anyways, I strongly recommend using David Mosberger's libunwind > implementation. I consider any ia64 linux machine which doesn't have it > installed to be broken. The gcc libunwind is probably never going to be > as good as the one David Mosberger wrote. I agree than HP's libunwind is more robust. The problem is that GCC 3.4.x requires a libunwind that conforms to the extended unwind ABI: http://www.kernel.org/pub/linux/devel/gcc/unwind and older systems don't have it (e.g. RHEL 3). > That said, it would be nice to fix the gcc unwinder if we can. The code > in question is in Jakub's patch that added the MD_HANDLE_UNWABI support. > So it has been there since the beginning for this macro. > http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00940.html Right, but the very same problem exists for MD_FALLBACK_FRAME_STACK_FOR. > I find it curious that there are some unexplained differences between > the MD_HANDLE_UNWABI and MD_FALLBACK_FRAME_STACK_FOR macros. The latter > supports fpsr for instance, and the former does not. There is also a > difference for psp. And the code at the end of each macro is > difference. It is this last bit you are complaining about. Some of > these differences are probably bugs. MD_HANDLE_UNWABI need not do as much work as MD_FALLBACK_FRAME_STACK_FOR because of the presence of unwind info, so I think differences are expected. > Maybe changes to the linux kernel and/or glibc have affected this code, > in which case we may need different versions for different kernel/glibc > versions. Or maybe smarter code that works with every linux kernel > and/or glibc version. I'm just guessing here. There is probably a > reason why Jakub included that code in his patch, but I don't know > offhand what it is. The current code works only if the signal is triggered in leaf functions. Maybe that was enough in most cases, but it is not for Ada. > I've never looked at the low level details of the unwinder, and how it > interacts with signal stack frames, so I'm not sure how much help I can > be here. Thanks for your feedback. We have a fix that passes all our internal tests, both on RHEL 3 which uses MD_FALLBACK_FRAME_STACK_FOR and on SLES 9 which uses MD_HANDLE_UNWABI. I'll submit it shortly. -- Eric Botcazou
