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 <[email protected]>
Signed-off-by: Marco Elver <[email protected]>
---
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
Hi Marco,
On Tue, Jun 16, 2020 at 1:15 AM Marco Elver <[email protected]> wrote:
>
> 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 <[email protected]>
> Signed-off-by: Marco Elver <[email protected]>
> ---
I am happy to see the `__GCC4_has_attribute` workaround is useful
outside the file, too (originally the list was meant to be used inside
the file itself, but I see it is good to reuse it).
Reviewed-by: Miguel Ojeda <[email protected]>
Cheers,
Miguel
On Tue, Jun 16, 2020 at 01:15:29AM +0200, Marco Elver wrote:
> 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 <[email protected]>
> Signed-off-by: Marco Elver <[email protected]>
> ---
>
> 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.
Yeah, argh! So I only saw this thread now, even though I'd already
pushed out x86/entry to tip last night due to getting:
301805 N + Jun 16 kernel test rob (5.8K) [peterz-queue:x86/entry] BUILD SUCCESS 8e8bb06d199a5aa7a534aa3b3fc0abbbc11ca438
Why that thing is claiming SUCCESS when it introduces a build error I
don't know.
Anyway, let me go push this thing on top.
On Tue, Jun 16, 2020 at 03:19:21PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 16, 2020 at 01:15:29AM +0200, Marco Elver wrote:
> > 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 <[email protected]>
> > Signed-off-by: Marco Elver <[email protected]>
> > ---
> >
> > 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.
>
> Yeah, argh! So I only saw this thread now, even though I'd already
> pushed out x86/entry to tip last night due to getting:
>
> 301805 N + Jun 16 kernel test rob (5.8K) [peterz-queue:x86/entry] BUILD SUCCESS 8e8bb06d199a5aa7a534aa3b3fc0abbbc11ca438
>
> Why that thing is claiming SUCCESS when it introduces a build error I
> don't know.
>
Hi Peter,
Sorry for the misunderstanding, some folks complained that it's too
noisy when there're only new warnings in a "BUILD REGRESSION" report,
so we changed to use "BUILD SUCCESS" if there's no new build error. To
avoid misunderstanding, we'll change build complete report title to
"BUILD SUCCESS WITH WARNING" for new warnings.
Best Regards,
Rong Chen
The following commit has been merged into the x86/entry branch of tip:
Commit-ID: 33aea07f30c261eff7ba229f19fd1b161e0fb851
Gitweb: https://git.kernel.org/tip/33aea07f30c261eff7ba229f19fd1b161e0fb851
Author: Marco Elver <[email protected]>
AuthorDate: Tue, 16 Jun 2020 01:15:29 +02:00
Committer: Peter Zijlstra <[email protected]>
CommitterDate: Tue, 16 Jun 2020 15:35:02 +02:00
compiler_attributes.h: Support no_sanitize_undefined check with GCC 4
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 <[email protected]>
Signed-off-by: Marco Elver <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Reviewed-by: Miguel Ojeda <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
---
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 cdf0165..c8f03d2 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
On Wed, Jun 17, 2020 at 09:00:51AM +0800, Rong Chen wrote:
> On Tue, Jun 16, 2020 at 03:19:21PM +0200, Peter Zijlstra wrote:
> > 301805 N + Jun 16 kernel test rob (5.8K) [peterz-queue:x86/entry] BUILD SUCCESS 8e8bb06d199a5aa7a534aa3b3fc0abbbc11ca438
> >
> > Why that thing is claiming SUCCESS when it introduces a build error I
> > don't know.
> Sorry for the misunderstanding, some folks complained that it's too
> noisy when there're only new warnings in a "BUILD REGRESSION" report,
> so we changed to use "BUILD SUCCESS" if there's no new build error. To
> avoid misunderstanding, we'll change build complete report title to
> "BUILD SUCCESS WITH WARNING" for new warnings.
Thanks Rong!