linux-kernel - Re: [PATCH] ARM: do not assemble iwmmxt.S with LLVM toolchain

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKwvOd=SusRJxzKqq=tBGgjq0tdcgeA1ukK79PyMjadWB8w=Qw@mail.gmail.com>
Date:   Mon, 13 Apr 2020 12:26:16 -0700
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Andrew Lunn <andrew@...n.ch>, Jian Cai <caij2003@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Peter Smith <Peter.Smith@....com>,
        Stefan Agner <stefan@...er.ch>,
        David Howells <dhowells@...hat.com>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
        Manoj Gupta <manojgupta@...gle.com>,
        Benjamin Gaignard <benjamin.gaignard@...aro.org>,
        "Joel Fernandes (Google)" <joel@...lfernandes.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>,
        Ilie Halip <ilie.halip@...il.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Sami Tolvanen <samitolvanen@...gle.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Arnd Bergmann <arnd@...db.de>,
        "Steven Rostedt (VMware)" <rostedt@...dmis.org>,
        Jian Cai <jiancai@...gle.com>,
        Doug Anderson <armlinux@...isordat.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Patrick Bellasi <patrick.bellasi@....com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Tejun Heo <tj@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] ARM: do not assemble iwmmxt.S with LLVM toolchain

On Fri, Apr 10, 2020 at 11:34 AM Russell King - ARM Linux admin
<linux@...linux.org.uk> wrote:
>
> On Fri, Apr 10, 2020 at 06:59:48PM +0200, Andrew Lunn wrote:
> > On Thu, Apr 09, 2020 at 04:27:26PM -0700, Jian Cai wrote:
> > > iwmmxt.S contains XScale instructions
> >
> > Dumb question....
> >
> > Are these Xscale instructions? My understanding is that they are an
> > instruction set of their own, implementing something similar to IA-32
> > MMX.
> >
> > Would it be more accurate to say CLANG does not support the iwmmxt
> > instruction set?
>
> Yes, because the XScale core on its own (otherwise known as 80200)
> doesn't support iWMMXT.
>
> It's worth pointing out that the iWMMXT instruction set uses the
> co-processor #1 instruction space as defined by the ARMv5 ARM ARM,
> which is also the FPA (floating point accelerator) instruction
> space - which is the FP instruction set prior to VFP.

Reusing instruction encoding space? :-X  I'll have to look and see how
we define cases like this in LLVM.

>
> The LDFP and similar instructions that binutils decodes the opcodes
> as are FPA instructions, and the LDC2 instructions are their "generic
> co-processor" versions where there's no FPA instruction that matches
> the op-code.
>
> I'll also point out that the reason the iWMMXT code has never been
> ported to Thumb2 is because there are no equivalents for the
> co-processor instructions in the Thumb2 instruction set defined in
> ARMv5.  Hence why the file has a .arm.  So, the fact the file hasn't
> changed for a long time and hasn't been updated with "improvements"
> such as Thumb2 kernels is because that's completely irrelevent to
> the ISA.
>
> It is an example of code that has become stable and mature, and
> requires no maintanence with GNU toolchains.

I agree.  I think this is something we can mark broken for our
toolchain in Kconfig for the time being, and revisit once we have more
resources to implement (leaving the sources as is).

-- 
Thanks,
~Nick Desaulniers