All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: kbuild-all@lists.01.org
Subject: [PATCH] compiler_attributes.h: Support no_sanitize_undefined check with GCC 4
Date: Tue, 16 Jun 2020 01:15:29 +0200	[thread overview]
Message-ID: <20200615231529.GA119644@google.com> (raw)
In-Reply-To: <202006160328.6MfJNuqX%lkp@intel.com>

[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]

UBSAN is supported since GCC 4.9, which unfortunately did not yet have
__has_attribute(). To work around, the __GCC4_has_attribute workaround
requires defining which compiler version supports the given attribute.

In the case of no_sanitize_undefined, it is the first version that
supports UBSAN, which is GCC 4.9.

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Marco Elver <elver@google.com>
---

Doing a 'make W=1' with GCC 4.9 and the provided config fixes the build
robot's report.

Peter: Feel free to either squash this patch into the one adding
__no_sanitize_undefined or apply on top.

Although at this point we don't have any users of
__no_sanitize_undefined anymore since objtool resolved the noinstr
problem for UBSAN differently. We should probably keep the attribute
around because eventually somebody will need it.

Thanks,
-- Marco

---
 include/linux/compiler_attributes.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/compiler_attributes.h b/include/linux/compiler_attributes.h
index cdf016596659..c8f03d2969df 100644
--- a/include/linux/compiler_attributes.h
+++ b/include/linux/compiler_attributes.h
@@ -40,6 +40,7 @@
 # define __GCC4_has_attribute___noclone__             1
 # define __GCC4_has_attribute___nonstring__           0
 # define __GCC4_has_attribute___no_sanitize_address__ (__GNUC_MINOR__ >= 8)
+# define __GCC4_has_attribute___no_sanitize_undefined__ (__GNUC_MINOR__ >= 9)
 # define __GCC4_has_attribute___fallthrough__         0
 #endif
 
-- 
2.27.0.290.gba653c62da-goog

WARNING: multiple messages have this Message-ID (diff)
From: Marco Elver <elver@google.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: kernel test robot <lkp@intel.com>,
	kbuild-all@lists.01.org,
	Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: [PATCH] compiler_attributes.h: Support no_sanitize_undefined check with GCC 4
Date: Tue, 16 Jun 2020 01:15:29 +0200	[thread overview]
Message-ID: <20200615231529.GA119644@google.com> (raw)
In-Reply-To: <202006160328.6MfJNuqX%lkp@intel.com>

UBSAN is supported since GCC 4.9, which unfortunately did not yet have
__has_attribute(). To work around, the __GCC4_has_attribute workaround
requires defining which compiler version supports the given attribute.

In the case of no_sanitize_undefined, it is the first version that
supports UBSAN, which is GCC 4.9.

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Marco Elver <elver@google.com>
---

Doing a 'make W=1' with GCC 4.9 and the provided config fixes the build
robot's report.

Peter: Feel free to either squash this patch into the one adding
__no_sanitize_undefined or apply on top.

Although at this point we don't have any users of
__no_sanitize_undefined anymore since objtool resolved the noinstr
problem for UBSAN differently. We should probably keep the attribute
around because eventually somebody will need it.

Thanks,
-- Marco

---
 include/linux/compiler_attributes.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/compiler_attributes.h b/include/linux/compiler_attributes.h
index cdf016596659..c8f03d2969df 100644
--- a/include/linux/compiler_attributes.h
+++ b/include/linux/compiler_attributes.h
@@ -40,6 +40,7 @@
 # define __GCC4_has_attribute___noclone__             1
 # define __GCC4_has_attribute___nonstring__           0
 # define __GCC4_has_attribute___no_sanitize_address__ (__GNUC_MINOR__ >= 8)
+# define __GCC4_has_attribute___no_sanitize_undefined__ (__GNUC_MINOR__ >= 9)
 # define __GCC4_has_attribute___fallthrough__         0
 #endif
 
-- 
2.27.0.290.gba653c62da-goog

  reply	other threads:[~2020-06-15 23:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-15 19:48 [peterz-queue:x86/entry 5/8] include/linux/compiler-gcc.h:153:5: note: in expansion of macro '__has_attribute' kernel test robot
2020-06-15 23:15 ` Marco Elver [this message]
2020-06-15 23:15   ` [PATCH] compiler_attributes.h: Support no_sanitize_undefined check with GCC 4 Marco Elver
2020-06-16 13:09   ` Miguel Ojeda
2020-06-16 13:19   ` Peter Zijlstra
2020-06-16 13:19     ` Peter Zijlstra
2020-06-17  1:00     ` Rong Chen
2020-06-17  1:00       ` [kbuild-all] " Rong Chen
2020-06-17  8:30       ` Peter Zijlstra
2020-06-17  8:30         ` [kbuild-all] " Peter Zijlstra
2020-06-17  8:30   ` [tip: x86/entry] " tip-bot2 for Marco Elver

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=20200615231529.GA119644@google.com \
    --to=elver@google.com \
    --cc=kbuild-all@lists.01.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.