In D90898#2496725, @compnerd wrote:In D90898#2384775, @rprichard wrote:In D90898#2379387, @compnerd wrote:Could you add a bit of a comment explaining why the XOM case is not protected against?
I think I can expand on the comment.
libunwind can be used for generating backtraces during regular execution (e.g. profiling) and crashing if the XOM is in use seems unfortunate.
For profiling, I assume the unwind info needs to be accurate at every instruction? I know that's definitely not the case for AArch64, but I thought it's still only mostly-accurate on other archs? I don't *really* know that unwinding through a signal handler is important for Android, but I don't know how to rule it out either, and we do have a test for it. I think the test predated Android's libunwindstack unwinder. Maybe someone could be using _Unwind_Backtrace in a segfault handler, and that probably avoids the async-unwind-info problem most of the time. But I also don't think that's how third-party Android crash dumpers work.
Sure, though, libunwind is generic and is used outside of android as well, including other AArch64 targets, so we do need to consider those use cases while making changes.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Yesterday
Wed, Jan 13
Tue, Jan 12
Can I get a code-owner to review this?
Enable unwind_leaffunction.pass.cpp for AArch64 Linux.
Thu, Jan 7
Thu, Dec 17
Rename flag to COMPILER_RT_BUILTINS_HIDE_SYMBOLS.
I also think this is a good change.
Wed, Dec 16
I'm using this change in https://android-review.googlesource.com/c/toolchain/llvm_android/+/1532841.
Dec 16 2020
It looks OK to me.
Dec 11 2020
Keep exporting these symbols on Android for compatibility.
Dec 10 2020
I assume the LIBUNWIND_HERMETIC_STATIC_LIBRARY setting isn't used on Darwin -- it leaves unw_* symbols as Extern and not PrivateExtern. Maybe the CMake file could reject that flag on Darwin instead of trying to make it work.
Fix LIBUNWIND_HERMETIC_STATIC_LIBRARY on macOS.
Dec 9 2020
Dec 2 2020
That could work. Some similar approaches:
- process_vm_readv
- pipe+write
- open /proc/self/mem
Update comments.
Nov 30 2020
Add +/- to __compiler_rt_scalbnX comment.
Rename new fmax/scalbn fp_lib.h params from a/b to x/y for consistency with the new tests and with the existing __compiler_rt_logb*.
Nov 23 2020
Remove obsoleted crt_fmax[f] and crt_scalbn[f] functions.
The __compiler_rt_{logb,scalbn,fmax}* functions don't work with x87 extended-precision FP, and I think FPUtil would handle that. Perhaps the existing inline functions could be extended to support x87, though.
Nov 19 2020
The existing __compiler_rt_logb* inline functions were also added to address PR32279, in D49514. On Android, all of fmax*/logb*/scalbn* are in libm, not libc. I commented more on the bug: https://bugs.llvm.org/show_bug.cgi?id=32279#c7.
Switch scalbn calls in ppc/divtc3.c to __compiler_rt_scalbn. I verified that, after doing so, libclang_rt.builtins-powerpc64le.a has no unresolved symbols for fmax*/logb*/scalbn*.
With this change, I think PR32279 is still an issue with non-standard FP formats, like the x86 80-bit extended-precision format. In principle, it seems straightforward to extend the __compiler_rt_* inline functions to handle that format.
Nov 10 2020
In D90898#2379387, @compnerd wrote:Could you add a bit of a comment explaining why the XOM case is not protected against?
Nov 5 2020
Sep 24 2020
Sep 23 2020
Sep 21 2020
Thanks for the review. It looks like I still need someone from the libunwind group to accept it, though.
Thanks for the review. It looks like I still need someone from the libunwind group to accept it, though.
Sep 17 2020
I uploaded the Android benchmark I used: https://gist.github.com/rprichard/1688de36f0132a40294adb0409189533.
This change enables the FrameHeaderCache for EHABI.
Apply clang-format fix.
I think these libunwind tests are relying on the signal trampoline having "good enough" unwind info, but AFAIK, that's not the case with the signal trampoline (__kernel_rt_sigreturn) in the AArch64 Linux vDSO. There was a commit recently adjusting .cfi_startproc to let the unwinder find the vDSO's FDE, but then this was quickly reverted. The FDE change allowed libgcc to find the FDE, and that broke glibc pthread cancellation somehow, so the FDE was then removed:
Sep 16 2020
Abandoned in favor of D87750.
This seems like a bad name.
Rename dso_length to text_segment_length.
Adding @saugustine -- this patch makes the frame header cache one word larger per entry.
Stylistic change.
I uploaded D87750, an alternative to this patch.
An alternative to D86256.
Sep 15 2020
Just want to comment "Or use LLD, which automatically inserts the terminator" - the zero terminator CIE is to work around a glibc issue D46566
Sep 14 2020
In D86256#2270331, @mstorsjo wrote:The commit description talks about making the caching optional, but I don't really see that aspect in the patch - or maybe I'm just not studying it closely enough?
I think I'm fine with this revision. I was wondering if the two functions should be removed from the GNU libsupc++'s cxxabi.h as well, which also declares both of the functions with an int return type. (i.e. It has the same issue as LLVM's cxxabi.h.)
Sep 9 2020
Sep 8 2020
Use -1 to indicate "search all cache entries".
In D86748#2262437, @compnerd wrote:Why not use -1 as the indicator instead of 0?
Sep 3 2020
The Linux ABI Extensions spec describes the binary search table of .eh_frame_hdr as optional, so maybe falling back to .eh_frame scanning could be necessary to accommodate some ELF files? I wonder what situation results in an omitted search table. ld.bfd does have code for outputting .eh_frame_hdr without a search table.
Sep 2 2020
On second thought, maybe I don't actually need this change, and the includes still seem like a mess in libunwind. Maybe it makes more sense to do a larger revision eventually.
In D86768#2253572, @saugustine wrote:I am going to accept this, since no one else seems to be able to review it. But the problem here is that no one really knows what a simplified ifdef chain with the same functionality looks like. I tried a couple of times and failed miserably.
So if this works, great! If not, we will need to revert it quickly.
Do I need an approval from a libunwind group member?
Aug 28 2020
Remove most of the previous change. Add a comment about Apple/armv7k.
In D86767#2244767, @steven_wu wrote:Sorry for the inconvenience that libunwind is not really buildable for armv7 from iOS SDK. You can build a single threaded version without referring to those interfaces. If this is really troublesome for you, feel free to file a bug report and we can see what can be done here.
If the unwinder uses dl_iterate_phdr, then entries that are automatically added to DwarfFDECache would become invalid if the module containing the entry were unloaded. (On Apple systems, DwarfFDECache registers dyldUnloadHook to remove unloaded entries.)
FWIW, when compact unwinding defers to DWARF (compactSaysUseDwarf), the unwinder begins a scan of .eh_frame at a given offset. Is that really the right behavior, or will the offset always point directly at the appropriate FDE (as with the DWARF index .eh_frame_hdr)?
FWIW, I compiled libunwind for Darwin, and I had trouble getting it to compile for armv7. Unwind-sjlj.c needs these things:
- #include <System/pthread_machdep.h>
- _pthread_getspecific_direct(__PTK_LIBC_DYLD_Unwind_SjLj_Key)
Rebase this change.
Split out the chain-of-ifdefs change into D86768.
Aug 27 2020
Aug 26 2020
Aug 25 2020
In D86372#2234459, @rprichard wrote:In D86372#2234249, @hans wrote:From the discussion on D86254, this should be cherry-picked to 11.x right?
Correct. This findUnwindSectionsByPhdr change (D86372) is needed for 11.
Aug 24 2020
In D86411#2233326, @mstorsjo wrote:Oh, ok, I see - maybe CMake deduced that the option wasn't needed in my case, when building with a compiler that defaults to a new enough version.