[libcxxabi patch] Add Registers_arm class and unw_getcontext implementation

[Nick Kledzik]

On Dec 17, 2013, at 6:04 PM, Nico Weber wrote:

> On Tue, Dec 17, 2013 at 2:12 PM, Nick Kledzik <kledzik at apple.com> wrote:
> 
> On Dec 17, 2013, at 1:40 PM, Nico Weber <thakis at chromium.org> wrote:
> 
>>  
>> 
>> I have not investigated deeply how _Unwind_VRS_Get() and friends work.  I thought part of the model was that arm could ship one static library that worked with all processors, and it did so via runtime checks for what registers the processor supported, and the core unwinder was always compiled to only use integer registers.  Meaning the float/vector registers where never saved/restored to the unwind buffer.  That is, calling a setFloatRegister() would change the real processor register and not something in the register set struct.
>> 
>> Would that work for unw_set_fpreg / unw_get_fpreg? (I don't know if users call this function directly). Also, 9.3 in http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038a/IHI0038A_ehabi.pdf (remark d, and instruction 11000111 0000iiii and similar) suggest that the exception bytecode modifies float registers in the virtual register bank, and if those modifications are done in real registers, wouldn't things be in an inconsistent state early during phase 2 unwinding, when the bytecode was processed once for phase 1 already?
> 
> Yes, it would have to know in phase 1 to not manipulate the real VFP registers.   
> 
> But Section 4.7 in that document sounds like VFP registers are lazily saved.  That initially, only integer registers are saved into the register state set.  Then when unwinding, if it sees a frame that says it saved VFP registers, only at that point are VFP registers saved to the register state set. 
> 
> I see. How about we leave the float register functions stubbed out for now, and we can fill them in once the integer bits of the unwinder work, and then we can figure out how to handle VFP registers :-)
Sounds good to me.

-Nick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131218/2ee5f784/attachment.html>