<div dir="ltr"><div><div>Hi Renato,<br><br>> Though, I thought we already had EHABI unwinding working... Is this in<br>
addition to Logan's work?<br><br></div>Yes.  This is the work to reduce the dependency on libgcc (by providing our own libunwind.)<br><br><br></div><div>Best regards,<br></div>Logan<br><div><div><div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Jun 4, 2014 at 6:48 PM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="">On 4 June 2014 00:28, Albert Wong (王重傑) <<a href="mailto:ajwong@google.com">ajwong@google.com</a>> wrote:<br>
> FYI, this is an incremental patch. The VFP support is still being fully<br>
> validated but there will be a followup patch soon. If you'd prefer, we can<br>
> push all of the VFP and core register bits at once. It'll be a bigish patch<br>
> though.<br>
<br>
</div>If that means full implementation of all types at once, I think it'd<br>
be better. The size is more boilerplate than actual logic, so it<br>
should be simpler to review one big lump of new functions than<br>
incremental differences thereafter.<br>
<br>
Though, I thought we already had EHABI unwinding working... Is this in<br>
addition to Logan's work?<br>
<span class=""><font color="#888888"><br>
--renato<br>
</font></span></blockquote></div><br></div></div></div></div></div>