User Details
- User Since
- Aug 7 2017, 9:53 PM (179 w, 6 d)
Sat, Jan 16
Thu, Jan 14
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
Dec 17 2020
Rename flag to COMPILER_RT_BUILTINS_HIDE_SYMBOLS.
I also think this is a good change.
Dec 16 2020
I'm using this change in https://android-review.googlesource.com/c/toolchain/llvm_android/+/1532841.
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
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
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".
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.
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.
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.