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

[Albert Wong (王重傑)]

Sounds good. Will just go with long longs then.
On 2 Jun 2014 07:43, "Nick Kledzik" <kledzik at apple.com> wrote:

> I think the history is that the libuwind API was designed to support local
> and “remote” unwinding.  Remote unwinding is inspecting the stack of
> another process, perhaps even on another machine. Hence, unw_content_t and
> unw_cursor_t are opaque and unw_word_t is big enough to hold an GPR on any
> cpu.
>
> Yes, it does seem like a mismatch for unw_word_t  to be 64-bit with ARM
> EHABI which is only used for “local” unwinding.  Personally, I think (2) is
> the least invasive change.  The printf format strings are only used with
> debug builds, so we don’t care about the performance of extending the args
> to 64-bits.
>
> -Nick
>
> On Jun 1, 2014, at 2:20 PM, Albert Wong (王重傑) <ajwong at google.com> wrote:
>
> [ +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/20140603/66cc3465/attachment.html>