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

> On Tue, Dec 17, 2013 at 2:12 PM, Nick Kledzik <[email protected]> wrote:
> 
> On Dec 17, 2013, at 1:40 PM, Nico Weber <[email protected]> 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

_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to