From: Clement Courbet <courbet@google.com>
To: unlisted-recipients:; (no To-header on input)
Cc: Nathan Chancellor <natechancellor@gmail.com>,
Kees Cook <keescook@chromium.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, Clement Courbet <courbet@google.com>,
linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com
Subject: [PATCH] x86: Alias memset to __builtin_memset.
Date: Tue, 24 Mar 2020 15:06:38 +0100 [thread overview]
Message-ID: <20200324140639.70079-1-courbet@google.com> (raw)
In-Reply-To: <20200323114207.222412-1-courbet@google.com>
Thanks for the comments. Answers below.
> This ifdef is unnecessary
> This needs to be within #ifndef CONFIG_FORTIFY_SOURCE
Thanks, fixed.
> shouldn't this just be done universally ?
It looks like every architecture does its own magic with memory
functions. I'm not very familiar with how the linux kernel is
organized, do you have a pointer for where this would go if enabled
globally ?
> Who's adding it for 64b?
> Any idea where it's coming from in your
> build? Maybe a local modification to be removed?
Actually this is from our local build configuration. Apparently this
is needed to build on some architectures that redefine common
symbols, but the authors seemed to feel strongly that this should be
on for all architectures. I've reached out to the authors for an
extended rationale.
On the other hand I think that there is no reason to prevent people
from building with freestanding if we can easily allow them to.
next prev parent reply other threads:[~2020-03-24 14:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-23 11:42 Clement Courbet
2020-03-23 15:47 ` Nathan Chancellor
2020-03-24 1:22 ` Nick Desaulniers
2020-03-24 1:26 ` Nick Desaulniers
2020-03-24 14:06 ` Clement Courbet [this message]
2020-03-24 17:29 ` Nick Desaulniers
2020-03-24 14:07 ` [PATCH v2] " Clement Courbet
2020-03-24 15:08 ` Joe Perches
2020-03-24 15:59 ` [PATCH v3] " Clement Courbet
2020-03-25 11:33 ` Bernd Petrovitsch
2020-03-24 16:02 ` [PATCH] " Clement Courbet
2020-03-25 7:59 ` Clement Courbet
2020-03-26 12:25 ` [PATCH v4] " Clement Courbet
2020-03-26 12:38 ` [PATCH] " Clement Courbet
2020-03-26 17:18 ` Nick Desaulniers
2020-03-27 4:06 ` Michael Ellerman
2020-03-27 17:12 ` Segher Boessenkool
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=20200324140639.70079-1-courbet@google.com \
--to=courbet@google.com \
--cc=bp@alien8.de \
--cc=clang-built-linux@googlegroups.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=natechancellor@gmail.com \
--cc=ndesaulniers@google.com \
--cc=tglx@linutronix.de \
--cc=x86@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
all inboxes | Powered by JetHome®