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

[Albert Wong (王重傑)]

[ +kledzik at apple.com ]

Adding Nick explicitly.

On Sun, Jun 1, 2014 at 1:14 PM, Albert Wong (王重傑) <ajwong at google.com> wrote:

> Sounds like a 32-bit unw_word_t is the general consensus (I'll
> double-check for ABI requirements on monday) . Couple of comments inline.
>
>
> On Sun, Jun 1, 2014 at 10:07 AM, David Majnemer <david.majnemer at gmail.com>
> wrote:
>
>> It should be a uint32_t for ARM If ABI, rather than API, compatibility
>> with HP libunwind is a goal.
>>
>
> I wan't quite sure how to interpret this statement. Do you mean preserving
> API compatibility is the goal?  If so, we're going to have some problems
> with floating point support.  Antoine (CC'd) is currently working on the
> patch and IIRC he's been finding a need to poke a few functions through
> into the libunwind API to facilitate the personality routines demand saving
> of VFP registers in phase 1 and then restoring them before phase 2.  This
> is mostly a heads up...we'll see what the code looks like when it's done.
>
>
>> 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.
>>>
>>
> This is possible, but I'm unsure what the benefit of providing an extra
> configuration option here is. Supporting multiple word sizes on one
> architecture sound like pretty scary bit of complexity to add...
>
> -Albert
>
>
>>
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/e112be33/attachment.html>