From: Masahiro Yamada <masahiroy@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Peter Smith <Peter.Smith@arm.com>, Stefan Agner <stefan@agner.ch>,
David Howells <dhowells@redhat.com>,
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
Manoj Gupta <manojgupta@google.com>,
Benjamin Gaignard <benjamin.gaignard@linaro.org>,
"Joel Fernandes \(Google\)" <joel@joelfernandes.org>,
Kristof Beyls <Kristof.Beyls@arm.com>,
Jian Cai <caij2003@gmail.com>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Ilie Halip <ilie.halip@gmail.com>,
Russell King - ARM Linux admin <linux@armlinux.org.uk>,
Krzysztof Kozlowski <krzk@kernel.org>,
Ard Biesheuvel <ardb@kernel.org>,
clang-built-linux <clang-built-linux@googlegroups.com>,
Sami Tolvanen <samitolvanen@google.com>,
Luis Lozano <llozano@google.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
"Steven Rostedt \(VMware\)" <rostedt@goodmis.org>,
Jian Cai <jiancai@google.com>, Stephen Hines <srhines@google.com>,
Doug Anderson <armlinux@m.disordat.com>,
Dan Williams <dan.j.williams@intel.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Nick Desaulniers <ndesaulniers@google.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Patrick Bellasi <patrick.bellasi@arm.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] ARM: do not assemble iwmmxt.S with LLVM toolchain
Date: Fri, 17 Apr 2020 23:12:35 +0900 [thread overview]
Message-ID: <CAK7LNAS-juF8dpeSVCuYQPwJ5HSQypFqOvesGFQR4bzTf23nUg@mail.gmail.com> (raw)
In-Reply-To: <202004150833.E2E9A89E0@keescook>
Hi
On Thu, Apr 16, 2020 at 12:44 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Wed, Apr 15, 2020 at 12:32:17PM +0200, Ard Biesheuvel wrote:
> > To reiterate my point: I strongly prefer minor asm surgery over
> > elaborate Kconfig plumbing if it means we can retain the functionality
> > even when using LLVM tools. In particular, the use of macros to
> > implement missing ISA support should be considered before any other
> > solution, as these are already being used widely across architectures
> > to fill in such gaps.
>
> Yeah, this seems like the right place to start from. It sounded like
> there were cases where the people with knowledge needed to accomplish
> the macro creation were not always immediately available. But, yes,
> let's get iwmmxt fixed up.
>
> > This code has been around since 2004. It has never been possible to
> > assemble it with Clang's assembler. So the only thing this patch gives
> > you is the ability to switch from a .config where IWMMXT was disabled
> > by hand to one where it gets disabled automatically by Kconfig.
>
> Right -- I meant "let's fix iwmmxt with macro magic" not "let's disable
> it". I did want to point out the Kconfig disabling may be needed in
> other cases.
>
> > So what hard-won ground are we losing here? Did IWMMXT recently get
> > enabled in a defconfig that you care about?
>
> It's a CI's ability to do randconfig builds to catch new stuff. (i.e.
> where "disabled by hand" isn't part of the process.) Since there are
> multiple CIs doing multi-architecture builds we need to get these things
> fixed upstream, not a CI's local patch stacks or Kconfig whitelists,
> etc. And when the expertise isn't available to fix arch-specific stuff,
> Kconfig negative depends seems like a reasonable middle ground. I, too,
> prefer fixes that allow Clang to do its work without wrecking things
> for GNU as.
>
> > I am not disagreeing with you here, and I have worked with Nick,
> > Nathan and Stefan on numerous occasions to get Clang related build
> > issues solved.
>
> Yup! Totally; this thread just looked very familiar to me from doing
> treewide stuff and I didn't want what I thought looked like the core
> points to get lost in the details. :)
>
> --
> Kees Cook
When I started to read this thread,
I just slightly preferred
depends on $(as-instr, <some iwmmxt instructions>)
over
depends on AS_IS_CLANG
because it is what we recently did for x86.
commit 5e8ebd841a44b895e2bab5e874ff7d333ca31135
But, Ard's macro approach seems even better.
I do not know how difficult to replace
the arch/x86/Kconfig.assembler with .macro
Anyway, arch/x86/Kconfig.assembler will be gone
when we raise the binutils version next time.
--
Best Regards
Masahiro Yamada
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-04-17 14:13 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-09 23:27 [PATCH] ARM: do not assemble iwmmxt.S with LLVM toolchain Jian Cai
2020-04-10 0:01 ` Nick Desaulniers
2020-04-10 0:12 ` Nathan Chancellor
2020-04-10 6:38 ` Sedat Dilek
2020-04-10 7:44 ` Nathan Chancellor
2020-04-10 9:56 ` Arnd Bergmann
2020-04-10 11:15 ` Ard Biesheuvel
2020-04-10 12:33 ` Russell King - ARM Linux admin
2020-04-10 13:09 ` Ard Biesheuvel
2020-04-13 20:45 ` Nick Desaulniers
2020-04-14 8:59 ` Ard Biesheuvel
2020-04-14 18:38 ` Nick Desaulniers
2020-04-14 20:53 ` Kees Cook
2020-04-15 10:32 ` Ard Biesheuvel
2020-04-15 12:58 ` Arnd Bergmann
2020-04-15 14:44 ` Russell King - ARM Linux admin
2020-04-19 11:08 ` Stefan Agner
2020-04-15 15:44 ` Kees Cook
2020-04-17 14:12 ` Masahiro Yamada [this message]
2020-04-13 19:23 ` Nick Desaulniers
2020-04-13 21:00 ` Russell King - ARM Linux admin
2020-11-04 20:44 ` Nick Desaulniers
2020-04-13 19:20 ` Nick Desaulniers
2020-04-13 21:15 ` Andrew Lunn
2020-04-10 16:59 ` Andrew Lunn
2020-04-10 18:34 ` Russell King - ARM Linux admin
2020-04-13 19:26 ` Nick Desaulniers
2020-04-13 21:53 ` Russell King - ARM Linux admin
2020-11-07 0:10 ` [PATCH v2] Make iwmmxt.S support Clang's integrated assembler Jian Cai
2020-11-07 8:29 ` Ard Biesheuvel
2020-11-10 1:55 ` Nick Desaulniers
2020-11-10 7:35 ` Ard Biesheuvel
2020-11-10 19:26 ` Nick Desaulniers
[not found] ` <CA+SOCLJSSR62VfWhKx9R1cxT-CHXD7RN08eJBYxUH8zzyWos9Q@mail.gmail.com>
2020-11-10 20:11 ` Nick Desaulniers
2020-11-10 20:38 ` Arnd Bergmann
2020-11-10 21:35 ` Ard Biesheuvel
2020-11-12 8:42 ` Ard Biesheuvel
2020-11-12 13:06 ` Arnd Bergmann
2020-11-12 20:07 ` [PATCH v3] " Jian Cai
2020-11-17 0:37 ` [PATCH v4] " Jian Cai
2020-11-17 1:20 ` Nick Desaulniers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAK7LNAS-juF8dpeSVCuYQPwJ5HSQypFqOvesGFQR4bzTf23nUg@mail.gmail.com \
--to=masahiroy@kernel.org \
--cc=Kristof.Beyls@arm.com \
--cc=Peter.Smith@arm.com \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=armlinux@m.disordat.com \
--cc=arnd@arndb.de \
--cc=benjamin.gaignard@linaro.org \
--cc=bgolaszewski@baylibre.com \
--cc=caij2003@gmail.com \
--cc=clang-built-linux@googlegroups.com \
--cc=dan.j.williams@intel.com \
--cc=dhowells@redhat.com \
--cc=ebiederm@xmission.com \
--cc=gregkh@linuxfoundation.org \
--cc=ilie.halip@gmail.com \
--cc=jiancai@google.com \
--cc=joel@joelfernandes.org \
--cc=keescook@chromium.org \
--cc=krzk@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=llozano@google.com \
--cc=manojgupta@google.com \
--cc=mchehab+samsung@kernel.org \
--cc=mhiramat@kernel.org \
--cc=ndesaulniers@google.com \
--cc=patrick.bellasi@arm.com \
--cc=rostedt@goodmis.org \
--cc=samitolvanen@google.com \
--cc=srhines@google.com \
--cc=stefan@agner.ch \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).