Messages in this thread | | | Subject | Re: rseq/arm32: choosing rseq code signature | From | "Richard Earnshaw (lists)" <> | Date | Wed, 17 Apr 2019 11:37:22 +0100 |
| |
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 >
| |