This is the mail archive of the
mailing list for the GCC project.
Re: updated for unwind-libunwind.c
>>>>> On 20 Nov 2003 15:04:49 -0800, Jim Wilson <firstname.lastname@example.org> said:
Jim> On Mon, 2003-11-17 at 22:10, David Mosberger wrote:
>> * config/t-libunwind: Mention unwind-c.c. (SHLIB_LC): Overwrite
>> the default-value from t-slibgcc-elf-ver and mention -lunwind so
>> that the resulting libgcc_s.so has the necessary DT_NEEDED entry
>> for libunwind. * unwind-libunwind.c (_Unwind_GetCFA): Implement.
>> (_Unwind_GetBSP) [UNW_TARGET_IA64]: New function.
Jim> Thanks. I checked this in.
Jim> I rewrote the ChangeLog entry a bit to match our conventions.
Jim> In particular, the DT_NEEDED comment should be in the
Jim> config/t-libunwind file not in the ChangeLog entry. There was
Jim> also a typo in your address.
OK, I'll try to do better next time.
Jim> I tested this with a debian testing (sarge) bootstrap and
Jim> testsuite run with --enable-libunwind-exceptions. The
Jim> libstdc++ testsuite gets 1403 more passes with this patch.
That wasn't expected, but it's certainly welcome news!
Jim> I see that all of those 1403 testcases fail if we don't use
Jim> libunwind. So there appears to be something seriously broken
Jim> with gcc's builtin unwinder. I haven't tried looking into this
I looked at the builtin unwinder for libc recently:
I don't think the C++ breakages are quite the same though, since the
libc problems were largely triggered by asynchronous unwinding in
response to a signal. However, I'm wondering whether the
.copy_state/.label_state may be getting in the way. I know the
builtin unwinder doesn't handle those quite right and newer GCC's emit
those directives much more frequently. When I fixed libunwind to
handle copy_state/label_state, I decided against updating the builtin
unwinder, since I was worried that the changes could be destabilizing.