[PATCH] D39251: [libunwind] Fix building for ARM with dwarf exception handling

[Martin Storsjö via Phabricator via cfe-commits]

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