Should unw_word_t be 32-bits on 32-bit platforms?

[Albert Wong (王重傑)]

Hello cfe-commits,

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.

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:

  (1) Continue making unw_word_t 64-bit regardless of the architecture's
native word size.
  (2) Change unw_word_t to 32-bit and cast every log line argument to
long-long so the format
       strings stay constant.
  (3) Change unw_word_t to 32-bit and use PRIXPTR in the format strings
(we'd have to add
       compatibility defines for platforms that don't have these macros) to
avoid needing the cast.

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.

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).

Suggestions?

-Albert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140601/1364b1d7/attachment.html>