Re: rseq/arm32: choosing rseq code signature

[Mathieu Desnoyers]

----- 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.

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

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com