<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>