Messages in this thread | | | Date | Mon, 15 Apr 2019 09:37:21 -0400 (EDT) | From | Mathieu Desnoyers <> | Subject | Re: rseq/arm32: choosing rseq code signature |
| |
----- 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").
Thanks,
Mathieu
-- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
| |