<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>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.</div><div><br></div><div>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. </div><div><br></div><div>-Nick</div><br><div><div>On Jun 1, 2014, at 2:20 PM, Albert Wong (王重傑) <<a href="mailto:ajwong@google.com">ajwong@google.com</a>> wrote:</div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">[ +<a href="mailto:kledzik@apple.com">kledzik@apple.com</a> ]</div><div class="gmail_extra"><br></div><div class="gmail_extra">Adding Nick explicitly.</div><div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Jun 1, 2014 at 1:14 PM, Albert Wong (王重傑) <span dir="ltr"><<a href="mailto:ajwong@google.com" target="_blank">ajwong@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">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.<div class="gmail_extra">
<br><br><div class="gmail_quote"><div>On Sun, Jun 1, 2014 at 10:07 AM, David Majnemer <span dir="ltr"><<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">It should be a uint32_t for ARM If ABI, rather than API, compatibility with HP libunwind is a goal.</div>
</blockquote><div><br></div></div><div>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.</div>
<div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote">
On Sat, May 31, 2014 at 10:33 PM, Jean-Daniel Dupas <span dir="ltr"><<a href="mailto:devlists@shadowlab.org" target="_blank">devlists@shadowlab.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div>Le 1 juin 2014 à 06:42, Saleem Abdulrasool <<a href="mailto:compnerd@compnerd.org" target="_blank">compnerd@compnerd.org</a>> a écrit :</div>
<div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, May 31, 2014 at 6:21 PM, Albert Wong (王重傑) <span dir="ltr"><<a href="mailto:ajwong@google.com" target="_blank">ajwong@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><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></blockquote><div><br></div><div>
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.</div>
<div> </div></div></div></div></blockquote><div><br></div></div><div>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.</div>
</div></div></blockquote></div></div></blockquote><div><br></div></div><div>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...</div>
<span><font color="#888888">
<div><br></div><div>-Albert</div></font></span><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>
<div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div>Suggestions?</div><span><font color="#888888">
<div><div><br></div><div>-Albert</div></div></font></span></div>
<br>_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org
</div></div>
_______________________________________________<br>cfe-commits mailing list<br><a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
</blockquote></div></div><span><font color="#888888"><br><div>
<span style="border-collapse:separate;border-spacing:0px"><div>-- Jean-Daniel</div><div><br></div><div><br></div></span><br>
</div>
<br></font></span></div><br>_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
<br></blockquote></div><br></div>
</div><br>_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
<br></blockquote></div></div><br></div></div>
</blockquote></div><br></div></div>
</blockquote></div><br></body></html>