<div dir="ltr">Hello cfe-commits,<div><br></div><div>As part of our work to implement EHABI, we experimentally tried to typedef unw_word_t so it was 32-bits on arm platforms.  It felt wasteful of memory and CPU cycles to work in 64-bits when everything on the architecture is 32-bits.</div>

<div><br></div><div>Unfortunately, this caused a problem with all the _LIBUNWIND_TRACE_UNWINDING format specifiers that specified %llX for unw_word_t values.  I can see 3 solutions to this:</div><div><br></div><div>  (1) Continue making unw_word_t 64-bit regardless of the architecture's native word size.</div>

<div>  (2) Change unw_word_t to 32-bit and cast every log line argument to long-long so the format</div><div>       strings stay constant.</div><div>  (3) Change unw_word_t to 32-bit and use PRIXPTR in the format strings (we'd have to add</div>

<div>       compatibility defines for platforms that don't have these macros) to avoid needing the cast.</div><div><br></div><div>Both options 2 and 3 are severely annoying code-wise. On the other hand, introducing inefficiency -- even if it's only for the exception handling path -- just to support tracing statements that are compiled out in release mode seems unfortunately.</div>

<div><br></div><div>My idealist side wants to suggest going with (3).  My more pragmatic "this likely is just noise compared to table lookups" side wants to go with (1).</div><div><br></div><div>Suggestions?</div>

<div><div><br></div><div>-Albert</div></div></div>