The previous definition of _LIBUNWIND_HIGHEST_DWARF_REGISTER seems to be a copy of the ARM64 value (introduced in SVN r276128); since the code actually hasn't compiled properly for arm in dwarf mode before, this hasn't actually been used. Set it to the correct value based on the UNW_ARM_* enum values.
Details
Diff Detail
Event Timeline
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).
src/Registers.hpp | ||
---|---|---|
1342 | 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. | |
src/UnwindLevel1.c | ||
79 | 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. |
Avoiding duplicating the highest register number, avoiding any further casts in log lines.
src/Registers.hpp | ||
---|---|---|
1481 | Why the change to mark these as mutable? |
src/Registers.hpp | ||
---|---|---|
1481 | These are touched from within getRegister, but we need to make getRegister const since it's used on a const Registers object in the dwarf codepath. |
Can we not use _LIBUNWIND_HIGHEST_DWARF_REGISTER here?