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

[David Majnemer]

It should be a uint32_t for ARM If ABI, rather than API, compatibility with
HP libunwind is a goal.


On Sat, May 31, 2014 at 10:33 PM, Jean-Daniel Dupas <devlists at shadowlab.org>
wrote:

>
> Le 1 juin 2014 à 06:42, Saleem Abdulrasool <compnerd at compnerd.org> a
> écrit :
>
> On Sat, May 31, 2014 at 6:21 PM, Albert Wong (王重傑) <ajwong at google.com>
> wrote:
>
>> 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).
>>
>
> I think I would agree with your idealist side.  What happens if someone
> tries to do bitwise operations on the incorrect type?  Hopefully, most of
> them would be caught by the compiler.  It feels that it might be nicer to
> go with option 3 even though it will cause a slight bit more churn.
>
>
>
> Instead of using PRIXPTR, you may just redefine your own macro next to the
> declaration of unw_word_t, so if someone want to use 64bit size unw_word_t
> on 32 bit platform, it will just have to change the typedef and macro
> definition at a single place.
>
> Suggestions?
>>
>> -Albert
>>
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>>
>
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
> -- Jean-Daniel
>
>
>
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140601/0c88e8ca/attachment.html>