Re: [Qemu-devel] [PATCH v3 04/11] linux-user: arm: set CPSR.E correctly for BE8 mode

[Peter Crosthwaite]

On Tue, Jun 23, 2015 at 1:04 AM, Peter Maydell <address@hidden> wrote:
> On 22 June 2015 at 23:48, Peter Crosthwaite
> <address@hidden> wrote:
>> On Thu, Jun 26, 2014 at 7:18 AM, Paolo Bonzini <address@hidden> wrote:
>>> Il 26/06/2014 16:15, Peter Maydell ha scritto:
>>>>
>>>> (There is code for handling CPSR_E in the kernel's start_thread()
>>>> macro but that is actually only called for starting new
>>>> processes, AFAICT.)
>>>
>>>
>>> Yes, you're right.
>>>
>>
>> So I am struggling on figuring out the need to have this extra state
>> of signal_cpsr_e. Is it still needed and to follow up, would something
>> similar be needed for SCTLR.E0E on AA64 support?
>
> The Linux userland ABI says:
>  (1) the ELF file defines whether an executable is BE8 or not
>  (2) this setting affects:
>     (a) whether we start at the process entry point in BE or LE
>     (b) whether we run signal handlers in BE or LE
>     (c) whether newly cloned threads start in BE or LE
>
> signal_cpsr_e is how this patch implements that -- we set it
> based on the ELF file flags, then set CPSR.E based on it:
>  * in main, for the initial thread
>  * in cpu_clone_regs, for subsequent threads
>  * in signal.c, for signal handlers
>
> For AArch64 BE we will need something similar. I don't know if
> there's somewhere more appropriate to store this "what's the
> ELF file endianness" state, but we do need to keep it somewhere...
>

So my current thinking is the new state captured in TB flags,
disas-context and this thing is just a bool for endianess. No sense of
CPSR.E or SCTLR.xx in the newly added state across the series. The TB
flag is then based on SCTLR.EE, SCTLR.E0E or CPSR.E depending on
processor mode. We already have arm_cpu_is_big_endian() to calculate
this.

That means that this logic would change signal_cpsr_e to a generic
endianess bool that will set both SCTLR_EL1.E0E and CPSR.E at all the
points Paolo is patching. SCTLR.EEs shouldn't need patching as
usermode shouldn't be affected (maybe add an assert in
arm_cpu_big_endian for usermode).

Regards,
Peter

> thanks
> -- PMM
>