On Tue, Apr 23, 2019 at 8:25 PM Kees Cook <keesc...@chromium.org> wrote: > On Tue, Apr 23, 2019 at 11:15 AM Nick Desaulniers <ndesaulni...@google.com> > wrote: > > On Tue, Apr 23, 2019 at 7:12 AM Mark Rutland <mark.rutl...@arm.com> wrote: > > > > > > On Mon, Apr 22, 2019 at 10:44:10AM -0700, Nick Desaulniers wrote: > > > > On Tue, Apr 16, 2019 at 9:03 PM Kees Cook <keesc...@chromium.org> wrote: > > > > > > > > > > On Tue, Apr 16, 2019 at 12:08 PM Mark Rutland <mark.rutl...@arm.com> > > > > > wrote: > > > > > > > > > > > > On Mon, Apr 15, 2019 at 10:22:27AM -0700, Nick Desaulniers wrote: > > > > > > > On Mon, Apr 15, 2019 at 10:06 AM Mark Rutland > > > > > > > <mark.rutl...@arm.com> wrote: > > > > > > > > It would be nice if we could simply rely on a more recent > > > > > > > > binutils these > > > > > > > > days, which supports the generic S<op0>_<op1>_<cn>_<Cm>_<op2> > > > > > > > > sysreg > > > > > > > > definition. That would mean we could get rid of the whole > > > > > > > > msr_s/mrs_s > > > > > > > > hack by turning that into a CPP macro which built that name. > > > > > > > > Mark, can you give me a test case for this? I'd like to check if > > > > clang's integrated assembler supports this or not, so we can file an > > > > issue and fix it if not. > > > > > > The below is a smoke test. The entire op0:op1:cn:cm:op2 space is 14 > > > bits, so it should be feasible to generate and run an exhautive test for > > > all encodings. > > > > > > I've included SYS and SYSL here too, since I strongly suspect we'll need > > > those going forward. > > > > > > Thanks > > > Mark. > > > > > > ---->8---- > > > /* > > > * ${CC} -c test.c > > > * > > > * OLD_* encodings already exist, NEW_* encodings haven't yet be > > > * allocated (per ARM DDI 0487D.a), but should assemble. All encodings > > > * chosen arbitrarily. > > > */ > > > > > > // OSDTRRX_EL1 > > > #define OLD_DBG_REG "s2_0_c0_c0_2" > > > #define NEW_DBG_REG "s2_7_c0_c15_0" > > > > > > // MIDR_EL1 > > > #define OLD_SYS_REG "s3_0_c0_c0_0" > > > #define NEW_SYS_REG "s3_6_c1_c0_7" > > > > > > #define REG(r) \ > > > asm volatile("msr " r ", xzr\n"); \ > > > asm volatile("mrs xzr, " r "\n") > > > > > > // DC IVAC, XZR > > > #define OLD_SYS "#0, c7, c6, #1" > > > #define NEW_SYS "#7, c15, c15, #7" > > > > > > #define NEW_SYSL_MIN "#0, c0, c0, #0" > > > #define NEW_SYSL_MAX "#7, c15, c15, #7" > > > > > > #define SYS(s) asm volatile("sys " s ", xzr\n") > > > #define SYSL(s) asm volatile("sysl xzr, " s "\n") > > > > > > void test(void) > > > { > > > REG(OLD_DBG_REG); > > > REG(NEW_DBG_REG); > > > > > > REG(OLD_SYS_REG); > > > REG(NEW_SYS_REG); > > > > > > SYS(OLD_SYS); > > > SYS(NEW_SYS); > > > > > > SYSL(NEW_SYSL_MIN); > > > SYSL(NEW_SYSL_MAX); > > > } > > > > Hmmm...yes looks like Clang's integrated assembler is missing support. > > https://godbolt.org/z/wDBpz4
It looks like you forgot to pass --target=aarch64-linux-gnu to clang here, which produces a build failure. This is the output with the added flag: https://godbolt.org/z/HYoEH1 > > https://bugs.llvm.org/show_bug.cgi?id=41573 > > https://github.com/ClangBuiltLinux/linux/issues/453 > > We'll follow up on getting that fixed. > > > > Kees, are you able to respin the patch with the above requested > > changes from Mark to the macros? Let me know what I can do to help. > > Doesn't this mean arm64 must raise their minimum binutils to 2.25? Is > that acceptable? I hadn't seen that question answered yet. (Maybe I > missed it?) Generally I'd say that's a bit too new for a minimum version. On the other hand, most distros I could find for arm64 have at least 2.25 or later, the oldest one I found being Debian Jessie. Ubuntu Trusty (14.04) was using 2.24 but has its end of support date this month, after five years. However, there are probably still cross-compile toolchains around that use older aarch64-binutils, so it probably hurts someone. Arnd