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
