On Wed, Jan 07, 2015 at 10:10:34AM +0000, Suzuki K. Poulose wrote: > On 07/01/15 05:52, Leo Yan wrote: > > Currently kernel has set the bit SCTLR_EL1.SED, so the SETEND > > instruction will be treated as UNALLOCATED; this error can be > > reproduced when ARMv8 cpu runs with EL1/aarch64 and EL0/aarch32 > > mode, finally kernel will trap the exception if the userspace > > libs use SETEND instruction. > > > > So this patch clears bit SCTLR_EL1.SED to support SETEND instruction. > > > The best way to do this, is via the instruction emulation framework > added by Punit, which handles the armv8 deprecated/obsoleted > instructions. This is now queued for 3.19. > I have a patchset which adds the 'SETEND' emulation support to the > framework. This will enable better handling of the feature, including > finding out the users of the deprecated instruction (when we switch to > the emulation mode). > > Btw, there is one open question that I am seeking answer for. > > What should be the endianness of the signal handlers ? Should we leave > it to the application ? Or restore the 'default' endianness for the > signal handler ?
I think we should restore the default endianness, otherwise you're essentially forcing signal handlers to do a setend as their first instruction to get into a consistent state. That also matches the endianness of the sigframe that we push onto the stack, right? setjmp/longjmp could be fun, but I think that an application would need to take care not to make endianness assumptions across those anyway. Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
