Re: rseq/arm32: choosing rseq code signature

[Richard Earnshaw (lists)]

On 16/04/2019 14:39, Mathieu Desnoyers wrote:
> ----- On Apr 15, 2019, at 9:37 AM, Mathieu Desnoyers mathieu.desnoyers@xxxxxxxxxxxx wrote:
> 
>> ----- On Apr 15, 2019, at 9:30 AM, peter maydell peter.maydell@xxxxxxxxxx wrote:
>>
>>> On Mon, 15 Apr 2019 at 14:11, Mathieu Desnoyers
>>> <mathieu.desnoyers@xxxxxxxxxxxx> wrote:
>>>>
>>>> ----- On Apr 11, 2019, at 3:55 PM, peter maydell peter.maydell@xxxxxxxxxx wrote:
>>>>
>>>>> On Thu, 11 Apr 2019 at 18:51, Mathieu Desnoyers
>>>>> <mathieu.desnoyers@xxxxxxxxxxxx> wrote:
>>>>>>  * This translates to the following instruction pattern in the T16 instruction
>>>>>>  * set:
>>>>>>  *
>>>>>>  * little endian:
>>>>>>  * def3        udf    #243      ; 0xf3
>>>>>>  * e7f5        b.n    <7f5>
>>>>>>  *
>>>>>>  * big endian:
>>>>>>  * e7f5        b.n    <7f5>
>>>>>>  * def3        udf    #243      ; 0xf3
>>>>>
>>>>> Do we really care about big-endian instruction-ordering for Thumb?
>>>>> It requires (AIUI) either an ARMv7R CPU which implements and sets
>>>>> SCTLR.IE to 1, or a v6-or-earlier CPU using BE32, and it's going to
>>>>> be even rarer than normal BE8 big-endian...
>>>>
>>>> I don't think we care enough about it to look for a trick to
>>>> turn the branch into something else (which would not branch away from the
>>>> udf instruction), but considering this signature will be ABI, it's good to
>>>> be thorough documentation-wise and cover all existing cases.
>>>
>>> I think if you want to document it it would be helpful to
>>> readers to make it clear that this is the ultra-rare
>>> big-endian-instruction-order "big endian Thumb", not the only
>>> moderately-rare little-endian-instructions-big-endian-data
>>> "big endian Thumb".
>>
>> I'm actually very much concerned about environments with big endian
>> data and little endian code. Which gcc compiler flags do I need to
>> use to test it ?
>>
>> I'm concerned about a signature mismatch between what is passed to
>> the rseq system call ("data-endian signature") and what is generated
>> in the code ("instruction-endian signature").
> 
> Based on this page: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/CDFBBCHB.html
> 
> My understanding is that the situation is as follows (please confirm):
> 
> - Prior to ARMv6, you could build and run code that is either big or little endian,
>   given you had a matching Linux kernel endianness. Code and data endianness needed
>   to match,
> - Starting from ARMv6, only little endian code is supported. The endianness for data
>   access can be changed through bit [9], the E bit, of the Program Status Register,
>   (mixed endianness)
> 
> Looking at ARM build options for gcc, it seems you can select either big or little
> endian (-mbig-endian or -mlittle-endian (default)) which affects both instruction and
> data endianness. So I suspect the -mbig-endian option is really only useful for
> pre-ARMv6.

-mbig-endian is still correct, even on later architectures.  The linker
gets involved, however, and (using the mapping symbol information) swaps
the code segments to little-endian form (this is why you have to use
.inst rather than .word when inserting instructions, so that the correct
mapping symbols are inserted).

> 
> For ARMv6+ mixed-endianness, it seems to be a mode that temporarily swap endianness
> of load/store instructions for specific memory accesses communicating with DMA devices,
> so I don't see any scenario where we can generate a binary that has little endian code
> and big endian data. If that is true, then it should be fine to declare the signature
> with ".arm .inst" and expect the data endianness to be the same as code endianness.
> 
> Am I missing something ?
> 
> Thanks,
> 
> Mathieu
>