mstorsjo added a comment. In https://reviews.llvm.org/D39251#906110, @compnerd wrote:
> Whats the motivation for adding DWARF based unwinding on ARM? What > environment is using this? AFAIK NetBSD does. And my actual target is for MinGW/ARM; it seemed to be less effort to make libunwind work for ARM/DWARF than to make the COFF/ARM backend in LLVM output EHABI (but I might have been mistaken). ================ Comment at: src/Registers.hpp:1342 } + static int lastDwarfRegNum() { return 287; } ---------------- compnerd wrote: > Can we not use `_LIBUNWIND_HIGHEST_DWARF_REGISTER` here? I guess we could - we could do that consistently throughout all the `Registers_*` classes then. Or even omit the method at all and just check `_LIBUNWIND_HIGHEST_DWARF_REGISTER` in the caller? Or perhaps the last part clashes with part of the (incomplete afaik?) intended design to support unwinding foreign systems as well. ================ Comment at: src/UnwindLevel1.c:79 _LIBUNWIND_TRACE_UNWINDING( "unwind_phase1(ex_ojb=%p): pc=0x%" PRIx64 ", start_ip=0x%" PRIx64 ", func=%s, lsda=0x%" PRIx64 ", personality=0x%" PRIx64 "", ---------------- compnerd wrote: > Please convert these to `%p` instead. The casting and conversion is kinda > ... unnecessary. Using `%p` wouldn't work when on 32 bit systems currently, while most of these fields are defined to be `uint64_t` except for the arm ehabi case. I guess I could look at how hard it would be to switch it to uint64_t for the arm/dwarf case as well. https://reviews.llvm.org/D39251 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits