----- On Apr 15, 2019, at 9:30 AM, peter maydell [email protected] wrote:
> On Mon, 15 Apr 2019 at 14:11, Mathieu Desnoyers > <[email protected]> wrote: >> >> ----- On Apr 11, 2019, at 3:55 PM, peter maydell [email protected] >> wrote: >> >> > On Thu, 11 Apr 2019 at 18:51, Mathieu Desnoyers >> > <[email protected]> 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"). Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
