[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libunwind-devel] Testing time
From: |
Lassi Tuura |
Subject: |
Re: [Libunwind-devel] Testing time |
Date: |
Tue, 29 Mar 2011 15:03:28 +0200 |
Hi,
> I went ahead and applied a bunch of patches yesterday. I believe it
> covers most of the things that were discussed on the list recently. I
> still haven't had a chance to review Lassi's performance fixes patch.
> Both 32 and 64 bit x86 are looking good (the same 4 known failures).
>
> Please pull, test and let me know if I broke your platform.
I have some reports of crashes on RHEL6 + GCC 4.6 + gold linker. LTO may be
involved, I am not sure.
There are sporadic failures in strange places like the code for parsing DWARF
CIEs: dwarf_readu32 < parse_cie < _ULx86_64_dwarf_extract_proc_info_from_fde <
_ULx86_64_dwarf_search_unwind_table < _ULx86_64_dwarf_find_proc_info <
fetch_proc_info.
One crash was triggered in GCC's own unwinder when throwing an exception:
read_encoded_value_with_base < _Unwind_IteratePhdrCallback < dl_iterate_phdr <
_Unwind_Find_FDE < uw_frame_state_for < _Unwind_RaiseException < __cxa_throw.
No libunwind code present in the process when this happened. It's possible both
stumbled over the same issue.
So far this looks like potentially new forms of wrong unwind info showing up,
or perhaps GCC 4.6 using (new?) DWARF info libunwind doesn't understand. If
it's the latter it seems GCC itself doesn't understand its own unwind info then.
At the moment we don't even know what's triggering these - the tool chain we
used was, ahem, a bit experimental. I'll report here if/when we can identify
the actual source.
Regards,
Lassi
Re: [Libunwind-devel] Testing time, Ken Werner, 2011/03/28
Re: [Libunwind-devel] Testing time,
Lassi Tuura <=
Re: [Libunwind-devel] Testing time, Lassi Tuura, 2011/03/29