Page MenuHomePhabricator

[libunwind] Use uint64_t for unw_word_t in ARM EHABI
AbandonedPublic

Authored by mstorsjo on Oct 25 2017, 1:31 AM.

Details

Reviewers
compnerd
jroelofs
Summary

This reduces the differences between the EHABI and DWARF cases.

This allows getting rid of some casts in _LIBUNWIND_TRACE_API log lines, making them match what's in UnwindLevel1.c for DWARF.

The only non-obvious detail is in _Unwind_VRS_Get_Internal (called via _Unwind_VRS_Get), where a void pointer is assumed to be uint32_t or uintptr_t (depending on the caller); this can no longer use unw_word_t directly as before.

Diff Detail

Event Timeline

mstorsjo created this revision.Oct 25 2017, 1:31 AM
compnerd edited edge metadata.Oct 26 2017, 7:30 PM

I dont think that this is correct. IIRC, the unwind specification expects unw_word_t to match uintptr_t (that is, it should be 32-bits on P32 environments).

I dont think that this is correct. IIRC, the unwind specification expects unw_word_t to match uintptr_t (that is, it should be 32-bits on P32 environments).

Ok, well currently it doesn't, on 32 bit x86 and ppc at least.

I dont think that this is correct. IIRC, the unwind specification expects unw_word_t to match uintptr_t (that is, it should be 32-bits on P32 environments).

I checked with GNU libunwind, and that seems to be true there. Updating our libunwind to match that doesn't seem to be too hard.

mstorsjo abandoned this revision.Oct 30 2017, 12:08 PM

This was made obsolete by D39365.