<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 30, 2014 at 1:39 PM, Logan Chien <span dir="ltr"><<a href="mailto:tzuhsiang.chien@gmail.com" target="_blank" class="cremed">tzuhsiang.chien@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi all,<br><br>Sorry for the late reply.  I am just feeling sick these days.  :-(<br></div></div>

</div></blockquote><div><br></div><div>No problem, thanks for the reply :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div></div>

It's
 fine with me to guard the r12 code with #if 
defined(LIBCXXABI_WITH_LIBGCC) or something like that, so that the code 
base can work with and without libgcc.<br><br>However, I have several questions on this patch.<br><br></div><div>(1)
 I am carious on the reason why does changing r12 will break libc++abi 
test (with your unwinder)?  IIRC, r12 is a scratch pointer which won't 
be saved between function calls.  Thus, most function will not (and 
should not) assume that r12 won't be clobbered between function calls.<br></div></div></blockquote><div><br></div><div>It hsa no effect on our tests, so it's not breaking anything. It just appeared completely unneeded given our implementation of the ARM EHABI unwinder.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>(2) I am afraid that we are not on the correct path.  Shouldn't the unwinder implement _Unwind_GetLanaguageSpecificData() and _Unwind_GetRegionStart() so that the other language-semantic library (say Obj-C) can implement their ABI library on top of these functions?<br>

</div></div></blockquote><div><br></div><div>AFAIK these methods are not part of the ARM EHABI, because these are passed to the personality function through the pr_cache. So, while we should implement them in the unwinder in general, we don't need to implement them for ARM EHABI. Hopefully we're not missing something here?</div>

<div><br></div><div>Cheers,</div><div>Dana</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>Thanks.<br></div><div><br></div>

<div>Sincerely,<br></div>Logan</div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Fri, May 30, 2014 at 9:51 AM, Jonathan Roelofs <span dir="ltr"><<a href="mailto:jonathan@codesourcery.com" target="_blank" class="cremed">jonathan@codesourcery.com</a>></span> wrote:<br>


</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div><br>
<br>
On 5/29/14, 6:53 PM, Dana Jansens wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
On Thu, May 29, 2014 at 8:27 PM, Jonathan Roelofs <<a href="mailto:jonathan@codesourcery.com" target="_blank" class="cremed">jonathan@codesourcery.com</a><br></div><div>
<mailto:<a href="mailto:jonathan@codesourcery.com" target="_blank" class="cremed">jonathan@codesourcery.<u></u>com</a>>> wrote:<br>
<br>
<br>
<br>
    On 5/28/14, 9:08 AM, Dana Jansens wrote:<br>
<br>
        -    // Copy the address of _Unwind_Control_Block to r12 so that<br></div>
        _Unwind___<u></u>GetLangauageSpecificData()<div><br>
        -    // and _Unwind_GetRegionStart() can return correct address.<br>
        -    _Unwind_SetGR(context, REG_UCB,<br></div>
        reinterpret_cast<uint32_t>(__<u></u>unwind_exception));<div><br>
<br>
<br>
Hey! Thanks for the pointers.<br>
<br>
    libgcc does in fact need us to pass the UCB in r12. See:<br></div>
    gcc-trunk-4.8/libgcc/arm/pr-__<u></u>support.c.<div><br>
<br>
<br>
It looks like we only need to call these methods on !ARM EHABI from our own<br>
libc++abi personality function. So I'm going to move them into that #if, along<br>
with the register setting, and avoided calling either method on ARM EHABI.<br>
<br>
<br>
    We should probably keep this, but put it under LIBCXXABI_USE_GLIBC for when<br>
    using libgcc's unwinder with libc++abi, as our unwinder implementation<br>
    doesn't do it that way.<br>
<br>
<br>
I think our local LIBCXXABI_USE_GLIBC is a mis-nomer and it's going to go away.<br>
We probably want to pull our unwind library out of libc++abi so that we can drop<br>
in GCC's if desired. It seems like our libc++abi shouldn't necessarily know what<br>
unwinder it will be using at compile time, but should just work with whichever<br>
gets used?<br>
</div></blockquote>
Good point.  Given that, maybe we ought to keep it in there.<div><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
However, for now we aren't passing the needed data to the personality function<br>
on EHABI yet upstream so we need to keep calling these _Unwind methods there<br>
still also. So I'm going to hold off on this patch until we upstream some other<br>
dependent pieces for this to make more sense.<br>
</blockquote></div>
SGTM<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks!<br>
- Dana<br>
</blockquote></div></div><div><div><div><div class="h5">
<br>
-- <br>
Jon Roelofs<br>
<a href="mailto:jonathan@codesourcery.com" target="_blank" class="cremed">jonathan@codesourcery.com</a><br>
CodeSourcery / Mentor Embedded<br></div></div><div class="">
______________________________<u></u>_________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank" class="cremed">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank" class="cremed">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-commits</a><br>
</div></div></div></blockquote></div><br></div>
</blockquote></div><br></div></div>