lkml.org 
[lkml]   [2019]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: rseq/arm32: choosing rseq code signature
From
Date
On 16/04/2019 14:39, Mathieu Desnoyers wrote:
> ----- On Apr 15, 2019, at 9:37 AM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote:
>
>> ----- On Apr 15, 2019, at 9:30 AM, peter maydell peter.maydell@linaro.org wrote:
>>
>>> On Mon, 15 Apr 2019 at 14:11, Mathieu Desnoyers
>>> <mathieu.desnoyers@efficios.com> wrote:
>>>>
>>>> ----- On Apr 11, 2019, at 3:55 PM, peter maydell peter.maydell@linaro.org wrote:
>>>>
>>>>> On Thu, 11 Apr 2019 at 18:51, Mathieu Desnoyers
>>>>> <mathieu.desnoyers@efficios.com> 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
>

\
 
 \ /
  Last update: 2019-04-17 12:38    [W:0.091 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site