Hi,
I've now also added a couple more changes:
* size to_clear_bitmap according to maxregno to be consistent with its use
* use directly TARGET_HARD_FLOAT instead of clear_vfpregs
Original message below (ChangeLog unchanged):
Function cmse_nonsecure_entry_clear_before_return has code to deal
Hi Richard,
On 07/07/17 15:19, Richard Earnshaw (lists) wrote:
Hmm, I think that's because really this is a partial conversion. It
looks like doing this properly would involve moving that existing code
to use sbitmaps as well. I think doing that would be better for
long-term maintenance persp
On 06/07/17 13:36, Thomas Preudhomme wrote:
> Hi Richard,
>
> On 28/06/17 16:56, Richard Earnshaw (lists) wrote:
>
>>>
>>
>> This is silently baking in dangerous assumptions about GCC's internal
>> numbering of the registers. That's not a good idea from a long-term
>> portability perspective.
>>
Hi Richard,
On 28/06/17 16:56, Richard Earnshaw (lists) wrote:
This is silently baking in dangerous assumptions about GCC's internal
numbering of the registers. That's not a good idea from a long-term
portability perspective.
At the very least you need to assert that all the interesting re
Hi Richard,
On 28/06/17 16:56, Richard Earnshaw (lists) wrote:
On 20/06/17 16:01, Thomas Preudhomme wrote:
Hi,
Function cmse_nonsecure_entry_clear_before_return has code to deal with
high VFP register (D16-D31) while ARMv8-M Baseline and Mainline both do
not support more than 16 double VFP reg
On 20/06/17 16:01, Thomas Preudhomme wrote:
> Hi,
>
> Function cmse_nonsecure_entry_clear_before_return has code to deal with
> high VFP register (D16-D31) while ARMv8-M Baseline and Mainline both do
> not support more than 16 double VFP registers (D0-D15). This makes this
> security-sensitive cod
