Re: [PATCH] include/linux/compiler*.h: Use feature checking instead of version checks for attributes
Hi Nick,
Actually, to acknowledge the comments to the other email...
On Tue, Aug 28, 2018 at 6:53 PM, Nick Desaulniers
wrote:
> On Tue, Aug 28, 2018 at 8:04 AM Miguel Ojeda
> wrote:
>>
>> Hi Nick,
>>
>> On Mon, Aug 27, 2018 at 7:43 PM, Nick Desaulniers
>> wrote:
>> > On Sun, Aug 26, 2018 at 10:58 AM Miguel Ojeda
>> > wrote:
>> >>
>> >> Instead of using version checks per-compiler to define (or not) each
>> >> attribute,
>> >> use __has_attribute to test for them, following the cleanup started with
>> >> commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h
>> >> mutually exclusive").
>> >>
>> >> All the attributes that are fairly common/standard (i.e. those that do not
>> >> require extra logic to define them) have been moved to a new file
>> >> include/linux/compiler_attributes.h. The attributes have been sorted
>> >> and divided between "required" and "optional".
>> >
>> > Nice! Thanks Miguel. Regarding sorting, I'm happy with that. In
>> > fact, some of the comments can be removed IMO, as the attributes have
>> > common definitions in the docs (maybe an added link to the gcc and
>> > clang attribute docs at the top of the file rather than per attribute
>> > comments).
>>
>> Thanks for the review!
>>
>> I thought about that, although there isn't a single page with them in
>> GCC (we could group them by type though: function ones, variable
>> ones... and then link to those).
>> On the other hand, maybe writing a
>> Doc/ file is better and allows us to write as much as one would like
>> about each of them (and a link to each page compiler's page about it,
>> etc.). I think in the end the Doc/ file might be the best, in order
>> not to crowd the header.
>
> A comment is closer to the source, but I guess that's bytes for each
> inclusion for every file. I don't feel passionate about this point
> one way or the other.
>
I think I will write a simple Doc/ file, link to it from the source,
and see if people like it.
>>
>> >
>> >>
>> >> Further, attributes that are already supported in gcc >= 4.6 and recent
>> >> clang
>> >> were simply made to be required (instead of testing for them):
>> >> * always_inline
>> >> * const (pure was already "required", by the way)
>> >> * gnu_inline
>> >
>> > There's an important test for gnu_inline that isn't checking that it's
>> > supported, but rather what the implicit behavior is depending on which
>> > C standard is being used. It's important not to remove that.
>>
>> Hm... I actually thought it was not available at some point before 4.6
>> and removed the #ifdef. The comment even says it is featuring
>> detecting it so that the old GCC inlining is used; but it shouldn't
>> matter if you always use it, no?
>
> Good point. Rather than defining it only if GNU inline is not the
> current behavior is a bit more verbose than just always defining it.
> This seems to confirm that that should work:
> https://godbolt.org/z/igwh32.
>
Great then! Thanks for confirming!
Cheers,
Miguel
Re: [PATCH] include/linux/compiler*.h: Use feature checking instead of version checks for attributes
Hi Nick,
Actually, to acknowledge the comments to the other email...
On Tue, Aug 28, 2018 at 6:53 PM, Nick Desaulniers
wrote:
> On Tue, Aug 28, 2018 at 8:04 AM Miguel Ojeda
> wrote:
>>
>> Hi Nick,
>>
>> On Mon, Aug 27, 2018 at 7:43 PM, Nick Desaulniers
>> wrote:
>> > On Sun, Aug 26, 2018 at 10:58 AM Miguel Ojeda
>> > wrote:
>> >>
>> >> Instead of using version checks per-compiler to define (or not) each
>> >> attribute,
>> >> use __has_attribute to test for them, following the cleanup started with
>> >> commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h
>> >> mutually exclusive").
>> >>
>> >> All the attributes that are fairly common/standard (i.e. those that do not
>> >> require extra logic to define them) have been moved to a new file
>> >> include/linux/compiler_attributes.h. The attributes have been sorted
>> >> and divided between "required" and "optional".
>> >
>> > Nice! Thanks Miguel. Regarding sorting, I'm happy with that. In
>> > fact, some of the comments can be removed IMO, as the attributes have
>> > common definitions in the docs (maybe an added link to the gcc and
>> > clang attribute docs at the top of the file rather than per attribute
>> > comments).
>>
>> Thanks for the review!
>>
>> I thought about that, although there isn't a single page with them in
>> GCC (we could group them by type though: function ones, variable
>> ones... and then link to those).
>> On the other hand, maybe writing a
>> Doc/ file is better and allows us to write as much as one would like
>> about each of them (and a link to each page compiler's page about it,
>> etc.). I think in the end the Doc/ file might be the best, in order
>> not to crowd the header.
>
> A comment is closer to the source, but I guess that's bytes for each
> inclusion for every file. I don't feel passionate about this point
> one way or the other.
>
I think I will write a simple Doc/ file, link to it from the source,
and see if people like it.
>>
>> >
>> >>
>> >> Further, attributes that are already supported in gcc >= 4.6 and recent
>> >> clang
>> >> were simply made to be required (instead of testing for them):
>> >> * always_inline
>> >> * const (pure was already "required", by the way)
>> >> * gnu_inline
>> >
>> > There's an important test for gnu_inline that isn't checking that it's
>> > supported, but rather what the implicit behavior is depending on which
>> > C standard is being used. It's important not to remove that.
>>
>> Hm... I actually thought it was not available at some point before 4.6
>> and removed the #ifdef. The comment even says it is featuring
>> detecting it so that the old GCC inlining is used; but it shouldn't
>> matter if you always use it, no?
>
> Good point. Rather than defining it only if GNU inline is not the
> current behavior is a bit more verbose than just always defining it.
> This seems to confirm that that should work:
> https://godbolt.org/z/igwh32.
>
Great then! Thanks for confirming!
Cheers,
Miguel
Re: [PATCH] include/linux/compiler*.h: Use feature checking instead of version checks for attributes
Hi Nick, On Tue, Aug 28, 2018 at 7:05 PM, Nick Desaulniers wrote: > On Tue, Aug 28, 2018 at 8:10 AM Miguel Ojeda > wrote: >> >> I addressed that in the email I sent afterwards: >> >> """ >> Note that: >> - assume_aligned came with gcc 4.9 >> - no_sanitize_address came with gcc 4.8 >> >> So if we feel it is important to have them there (before gcc 5), we >> would need here a quick version check here. >> """ >> >> The idea is that, in the future, whenever gcc 5 or later is the >> minimum version, we just get rid of the #ifdef block without touching >> the rest of the code :-) > > So if __has_attribute came with gcc 5, then that means that this patch > will break assume_aligned for gcc-4.9 users and no_sanitize_address > for gcc-4.8 and gcc-4.9 users? The slab allocator uses > assume_aligned, and no_sanitize_address for CONFIG_KASAN. Should this > patch ever come back through stable, Android and ChromeOS > gcc-4.9/KASAN builds will break. > Indeed, KASAN requires it: This is strictly a debugging feature and it requires a gcc version of 4.9.2 or later. Detection of out of bounds accesses to stack or global variables requires gcc 5.0 or later. So we should just support it. However, __no_sanitize_address is only used when CONFIG_KASAN is enabled (to define __no_kasan_or_inline). So I would say it is an attribute for a particular CONFIG (like those of sparse). Therefore, I think we should simply remove __no_sanitize_address for general use (let's see how it looks). For __assume_aligned, it is "only" an optimization, but I think it is a general one, so we should keep it in attributes.h; I will simply add the gcc 4.9 support knowledge. On that topic: actually, some of the attributes that we have that are "required" are not really "required" in the strict sense: we could test for them; but I wanted to minimize the amount of noise for gcc < 5 since we have to manually write the support table (and anyway most compilers support them). Whenever we are past gcc 5 in a few years, we could actually test for the non-strictly-required attribute if we want to be extra nice to new compilers :-) > I don't think we should leave that for a follow up; I would like to > see it as part of this patch. It's ok to have explicit version checks > for those 2 attributes since it's not possible to feature detect them > for the versions of gcc that we support in this code base. I think > you should add them in a v2 of this patch. Then we can point to this > commit as the *shining example* of how to do proper feature detection, > falling back to version checks only as a last resort. Thanks for the kind words! I also read your other comments in the previous email -- no comments on those. I will prepare v2. Cheers, Miguel
Re: [PATCH] include/linux/compiler*.h: Use feature checking instead of version checks for attributes
Hi Nick, On Tue, Aug 28, 2018 at 7:05 PM, Nick Desaulniers wrote: > On Tue, Aug 28, 2018 at 8:10 AM Miguel Ojeda > wrote: >> >> I addressed that in the email I sent afterwards: >> >> """ >> Note that: >> - assume_aligned came with gcc 4.9 >> - no_sanitize_address came with gcc 4.8 >> >> So if we feel it is important to have them there (before gcc 5), we >> would need here a quick version check here. >> """ >> >> The idea is that, in the future, whenever gcc 5 or later is the >> minimum version, we just get rid of the #ifdef block without touching >> the rest of the code :-) > > So if __has_attribute came with gcc 5, then that means that this patch > will break assume_aligned for gcc-4.9 users and no_sanitize_address > for gcc-4.8 and gcc-4.9 users? The slab allocator uses > assume_aligned, and no_sanitize_address for CONFIG_KASAN. Should this > patch ever come back through stable, Android and ChromeOS > gcc-4.9/KASAN builds will break. > Indeed, KASAN requires it: This is strictly a debugging feature and it requires a gcc version of 4.9.2 or later. Detection of out of bounds accesses to stack or global variables requires gcc 5.0 or later. So we should just support it. However, __no_sanitize_address is only used when CONFIG_KASAN is enabled (to define __no_kasan_or_inline). So I would say it is an attribute for a particular CONFIG (like those of sparse). Therefore, I think we should simply remove __no_sanitize_address for general use (let's see how it looks). For __assume_aligned, it is "only" an optimization, but I think it is a general one, so we should keep it in attributes.h; I will simply add the gcc 4.9 support knowledge. On that topic: actually, some of the attributes that we have that are "required" are not really "required" in the strict sense: we could test for them; but I wanted to minimize the amount of noise for gcc < 5 since we have to manually write the support table (and anyway most compilers support them). Whenever we are past gcc 5 in a few years, we could actually test for the non-strictly-required attribute if we want to be extra nice to new compilers :-) > I don't think we should leave that for a follow up; I would like to > see it as part of this patch. It's ok to have explicit version checks > for those 2 attributes since it's not possible to feature detect them > for the versions of gcc that we support in this code base. I think > you should add them in a v2 of this patch. Then we can point to this > commit as the *shining example* of how to do proper feature detection, > falling back to version checks only as a last resort. Thanks for the kind words! I also read your other comments in the previous email -- no comments on those. I will prepare v2. Cheers, Miguel
Re: [PATCH] include/linux/compiler*.h: Use feature checking instead of version checks for attributes
On Tue, Aug 28, 2018 at 8:10 AM Miguel Ojeda wrote: > > Hi Nick, > > On Mon, Aug 27, 2018 at 7:48 PM, Nick Desaulniers > wrote: > > On Mon, Aug 27, 2018 at 10:43 AM Nick Desaulniers > >> > + > >> > +/* > >> > + * Optional attributes: your compiler may or may not support them. > >> > + * > >> > + * To check for them, we use __has_attribute, which is supported on gcc > >> > >= 5, > >> > + * clang >= 2.9 and icc >= 17. In the meantime, to support 4.6 <= gcc < > >> > 5, > >> > + * we implement it by hand. > >> > + */ > >> > +#ifndef __has_attribute > >> > +#define __has_attribute(x) __GCC46_has_attribute_##x > >> > +#define __GCC46_has_attribute_assume_aligned 0 > >> > +#define __GCC46_has_attribute_designated_init 0 > >> > +#define __GCC46_has_attribute_externally_visible 1 > >> > +#define __GCC46_has_attribute_noclone 1 > >> > +#define __GCC46_has_attribute_optimize 1 > >> > +#define __GCC46_has_attribute_no_sanitize_address 0 > >> > +#endif > > > > And a follow up; I'm trying to understand what will happen in the case > > of say gcc 4.9 here. Were any of these supported between gcc 4.6 and > > 5.0? If so, then this code will not use them. It's simpler than > > explicit version checks, but it won't use features that are supported. > > > > I addressed that in the email I sent afterwards: > > """ > Note that: > - assume_aligned came with gcc 4.9 > - no_sanitize_address came with gcc 4.8 > > So if we feel it is important to have them there (before gcc 5), we > would need here a quick version check here. > """ > > The idea is that, in the future, whenever gcc 5 or later is the > minimum version, we just get rid of the #ifdef block without touching > the rest of the code :-) So if __has_attribute came with gcc 5, then that means that this patch will break assume_aligned for gcc-4.9 users and no_sanitize_address for gcc-4.8 and gcc-4.9 users? The slab allocator uses assume_aligned, and no_sanitize_address for CONFIG_KASAN. Should this patch ever come back through stable, Android and ChromeOS gcc-4.9/KASAN builds will break. I don't think we should leave that for a follow up; I would like to see it as part of this patch. It's ok to have explicit version checks for those 2 attributes since it's not possible to feature detect them for the versions of gcc that we support in this code base. I think you should add them in a v2 of this patch. Then we can point to this commit as the *shining example* of how to do proper feature detection, falling back to version checks only as a last resort. -- Thanks, ~Nick Desaulniers
Re: [PATCH] include/linux/compiler*.h: Use feature checking instead of version checks for attributes
On Tue, Aug 28, 2018 at 8:10 AM Miguel Ojeda wrote: > > Hi Nick, > > On Mon, Aug 27, 2018 at 7:48 PM, Nick Desaulniers > wrote: > > On Mon, Aug 27, 2018 at 10:43 AM Nick Desaulniers > >> > + > >> > +/* > >> > + * Optional attributes: your compiler may or may not support them. > >> > + * > >> > + * To check for them, we use __has_attribute, which is supported on gcc > >> > >= 5, > >> > + * clang >= 2.9 and icc >= 17. In the meantime, to support 4.6 <= gcc < > >> > 5, > >> > + * we implement it by hand. > >> > + */ > >> > +#ifndef __has_attribute > >> > +#define __has_attribute(x) __GCC46_has_attribute_##x > >> > +#define __GCC46_has_attribute_assume_aligned 0 > >> > +#define __GCC46_has_attribute_designated_init 0 > >> > +#define __GCC46_has_attribute_externally_visible 1 > >> > +#define __GCC46_has_attribute_noclone 1 > >> > +#define __GCC46_has_attribute_optimize 1 > >> > +#define __GCC46_has_attribute_no_sanitize_address 0 > >> > +#endif > > > > And a follow up; I'm trying to understand what will happen in the case > > of say gcc 4.9 here. Were any of these supported between gcc 4.6 and > > 5.0? If so, then this code will not use them. It's simpler than > > explicit version checks, but it won't use features that are supported. > > > > I addressed that in the email I sent afterwards: > > """ > Note that: > - assume_aligned came with gcc 4.9 > - no_sanitize_address came with gcc 4.8 > > So if we feel it is important to have them there (before gcc 5), we > would need here a quick version check here. > """ > > The idea is that, in the future, whenever gcc 5 or later is the > minimum version, we just get rid of the #ifdef block without touching > the rest of the code :-) So if __has_attribute came with gcc 5, then that means that this patch will break assume_aligned for gcc-4.9 users and no_sanitize_address for gcc-4.8 and gcc-4.9 users? The slab allocator uses assume_aligned, and no_sanitize_address for CONFIG_KASAN. Should this patch ever come back through stable, Android and ChromeOS gcc-4.9/KASAN builds will break. I don't think we should leave that for a follow up; I would like to see it as part of this patch. It's ok to have explicit version checks for those 2 attributes since it's not possible to feature detect them for the versions of gcc that we support in this code base. I think you should add them in a v2 of this patch. Then we can point to this commit as the *shining example* of how to do proper feature detection, falling back to version checks only as a last resort. -- Thanks, ~Nick Desaulniers
Re: [PATCH] include/linux/compiler*.h: Use feature checking instead of version checks for attributes
On Tue, Aug 28, 2018 at 8:04 AM Miguel Ojeda
wrote:
>
> Hi Nick,
>
> On Mon, Aug 27, 2018 at 7:43 PM, Nick Desaulniers
> wrote:
> > On Sun, Aug 26, 2018 at 10:58 AM Miguel Ojeda
> > wrote:
> >>
> >> Instead of using version checks per-compiler to define (or not) each
> >> attribute,
> >> use __has_attribute to test for them, following the cleanup started with
> >> commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h
> >> mutually exclusive").
> >>
> >> All the attributes that are fairly common/standard (i.e. those that do not
> >> require extra logic to define them) have been moved to a new file
> >> include/linux/compiler_attributes.h. The attributes have been sorted
> >> and divided between "required" and "optional".
> >
> > Nice! Thanks Miguel. Regarding sorting, I'm happy with that. In
> > fact, some of the comments can be removed IMO, as the attributes have
> > common definitions in the docs (maybe an added link to the gcc and
> > clang attribute docs at the top of the file rather than per attribute
> > comments).
>
> Thanks for the review!
>
> I thought about that, although there isn't a single page with them in
> GCC (we could group them by type though: function ones, variable
> ones... and then link to those).
> On the other hand, maybe writing a
> Doc/ file is better and allows us to write as much as one would like
> about each of them (and a link to each page compiler's page about it,
> etc.). I think in the end the Doc/ file might be the best, in order
> not to crowd the header.
A comment is closer to the source, but I guess that's bytes for each
inclusion for every file. I don't feel passionate about this point
one way or the other.
>
> >
> >>
> >> Further, attributes that are already supported in gcc >= 4.6 and recent
> >> clang
> >> were simply made to be required (instead of testing for them):
> >> * always_inline
> >> * const (pure was already "required", by the way)
> >> * gnu_inline
> >
> > There's an important test for gnu_inline that isn't checking that it's
> > supported, but rather what the implicit behavior is depending on which
> > C standard is being used. It's important not to remove that.
>
> Hm... I actually thought it was not available at some point before 4.6
> and removed the #ifdef. The comment even says it is featuring
> detecting it so that the old GCC inlining is used; but it shouldn't
> matter if you always use it, no?
Good point. Rather than defining it only if GNU inline is not the
current behavior is a bit more verbose than just always defining it.
This seems to confirm that that should work:
https://godbolt.org/z/igwh32.
>
> I just went looking for more info in d03db2bc2 ("compiler-gcc.h: Add
> __attribute__((gnu_inline)) to all inline declarations") and if I
> understood the commit message, the problem is compiling with implicit
> new standard in newer compilers which trigger the C90 behavior, while
> we need the old one --- but if we use gnu_inline, we are getting it
> regardless.
>
> I am sure I am missing something, but I think a clarification is
> needed (and in the code comment as well) -- a bit off-topic, anyway.
>
> [Also, I wouldn't define an attribute or not depending on some other
> condition. I would, instead, define something some other symbol with
> that logic (i.e. instead of using "__gnu_inline", because that is
> lying -- it is not using the attribute even if the compiler supports
> it).]
>
> >
> >>
> >> Finally, some other bits were cleaned up in the process:
> >> * __optimize: removed (unused in the whole kernel tree)
> >
> > A+ for removing dead code. I also don't see it used anywhere.
> >
> >> * __must_be_array: removed from -gcc and -clang (identical), moved to
> >> _types
> >
> > Yep, uses a builtin (we should add guards for that, later, in a
> > similar style change that guards the use of builtins). Looks good.
> >
> >> (it depends on the unconditionally used __builtin_types_compatible_p
> >> * Removes unneeded underscores on the attributes' names
> >
> > That doesn't sound right, but lets see what you mean by that.
>
> Some attributes used the __name__ syntax (i.e. inside the double
> parenthesis), others didn't. I simplified by removing all the extra
> underscores.
A+
>
> >
> >>
> >> There are some things that can be further cleaned up afterwards:
> >> * __attribute_const__: rename to __const
> >
> > This doesn't look correct to me; the kernel is full of call sites for
> > __attribute_const__. You can't rename the definition without renaming
>
> Of course it is full of use sites! That is why I said it is a possible
> cleanup for *afterwards* this patch :-)
>
> > all of the call sites (and that would be too big a change for this
> > patch, IMO). Skip the rename, and it also looks like you just removed
> > it outright (Oops).
>
> Not sure what you mean by this (?). The attribute is still there unchanged.
Nevermind, I misinterpretered this part of the patch.
>
> >
> >> * __noretpoline:
Re: [PATCH] include/linux/compiler*.h: Use feature checking instead of version checks for attributes
On Tue, Aug 28, 2018 at 8:04 AM Miguel Ojeda
wrote:
>
> Hi Nick,
>
> On Mon, Aug 27, 2018 at 7:43 PM, Nick Desaulniers
> wrote:
> > On Sun, Aug 26, 2018 at 10:58 AM Miguel Ojeda
> > wrote:
> >>
> >> Instead of using version checks per-compiler to define (or not) each
> >> attribute,
> >> use __has_attribute to test for them, following the cleanup started with
> >> commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h
> >> mutually exclusive").
> >>
> >> All the attributes that are fairly common/standard (i.e. those that do not
> >> require extra logic to define them) have been moved to a new file
> >> include/linux/compiler_attributes.h. The attributes have been sorted
> >> and divided between "required" and "optional".
> >
> > Nice! Thanks Miguel. Regarding sorting, I'm happy with that. In
> > fact, some of the comments can be removed IMO, as the attributes have
> > common definitions in the docs (maybe an added link to the gcc and
> > clang attribute docs at the top of the file rather than per attribute
> > comments).
>
> Thanks for the review!
>
> I thought about that, although there isn't a single page with them in
> GCC (we could group them by type though: function ones, variable
> ones... and then link to those).
> On the other hand, maybe writing a
> Doc/ file is better and allows us to write as much as one would like
> about each of them (and a link to each page compiler's page about it,
> etc.). I think in the end the Doc/ file might be the best, in order
> not to crowd the header.
A comment is closer to the source, but I guess that's bytes for each
inclusion for every file. I don't feel passionate about this point
one way or the other.
>
> >
> >>
> >> Further, attributes that are already supported in gcc >= 4.6 and recent
> >> clang
> >> were simply made to be required (instead of testing for them):
> >> * always_inline
> >> * const (pure was already "required", by the way)
> >> * gnu_inline
> >
> > There's an important test for gnu_inline that isn't checking that it's
> > supported, but rather what the implicit behavior is depending on which
> > C standard is being used. It's important not to remove that.
>
> Hm... I actually thought it was not available at some point before 4.6
> and removed the #ifdef. The comment even says it is featuring
> detecting it so that the old GCC inlining is used; but it shouldn't
> matter if you always use it, no?
Good point. Rather than defining it only if GNU inline is not the
current behavior is a bit more verbose than just always defining it.
This seems to confirm that that should work:
https://godbolt.org/z/igwh32.
>
> I just went looking for more info in d03db2bc2 ("compiler-gcc.h: Add
> __attribute__((gnu_inline)) to all inline declarations") and if I
> understood the commit message, the problem is compiling with implicit
> new standard in newer compilers which trigger the C90 behavior, while
> we need the old one --- but if we use gnu_inline, we are getting it
> regardless.
>
> I am sure I am missing something, but I think a clarification is
> needed (and in the code comment as well) -- a bit off-topic, anyway.
>
> [Also, I wouldn't define an attribute or not depending on some other
> condition. I would, instead, define something some other symbol with
> that logic (i.e. instead of using "__gnu_inline", because that is
> lying -- it is not using the attribute even if the compiler supports
> it).]
>
> >
> >>
> >> Finally, some other bits were cleaned up in the process:
> >> * __optimize: removed (unused in the whole kernel tree)
> >
> > A+ for removing dead code. I also don't see it used anywhere.
> >
> >> * __must_be_array: removed from -gcc and -clang (identical), moved to
> >> _types
> >
> > Yep, uses a builtin (we should add guards for that, later, in a
> > similar style change that guards the use of builtins). Looks good.
> >
> >> (it depends on the unconditionally used __builtin_types_compatible_p
> >> * Removes unneeded underscores on the attributes' names
> >
> > That doesn't sound right, but lets see what you mean by that.
>
> Some attributes used the __name__ syntax (i.e. inside the double
> parenthesis), others didn't. I simplified by removing all the extra
> underscores.
A+
>
> >
> >>
> >> There are some things that can be further cleaned up afterwards:
> >> * __attribute_const__: rename to __const
> >
> > This doesn't look correct to me; the kernel is full of call sites for
> > __attribute_const__. You can't rename the definition without renaming
>
> Of course it is full of use sites! That is why I said it is a possible
> cleanup for *afterwards* this patch :-)
>
> > all of the call sites (and that would be too big a change for this
> > patch, IMO). Skip the rename, and it also looks like you just removed
> > it outright (Oops).
>
> Not sure what you mean by this (?). The attribute is still there unchanged.
Nevermind, I misinterpretered this part of the patch.
>
> >
> >> * __noretpoline:
Re: [PATCH] include/linux/compiler*.h: Use feature checking instead of version checks for attributes
Hi Nick,
On Mon, Aug 27, 2018 at 7:48 PM, Nick Desaulniers
wrote:
> On Mon, Aug 27, 2018 at 10:43 AM Nick Desaulniers
>> > +
>> > +/*
>> > + * Optional attributes: your compiler may or may not support them.
>> > + *
>> > + * To check for them, we use __has_attribute, which is supported on gcc
>> > >= 5,
>> > + * clang >= 2.9 and icc >= 17. In the meantime, to support 4.6 <= gcc < 5,
>> > + * we implement it by hand.
>> > + */
>> > +#ifndef __has_attribute
>> > +#define __has_attribute(x) __GCC46_has_attribute_##x
>> > +#define __GCC46_has_attribute_assume_aligned 0
>> > +#define __GCC46_has_attribute_designated_init 0
>> > +#define __GCC46_has_attribute_externally_visible 1
>> > +#define __GCC46_has_attribute_noclone 1
>> > +#define __GCC46_has_attribute_optimize 1
>> > +#define __GCC46_has_attribute_no_sanitize_address 0
>> > +#endif
>
> And a follow up; I'm trying to understand what will happen in the case
> of say gcc 4.9 here. Were any of these supported between gcc 4.6 and
> 5.0? If so, then this code will not use them. It's simpler than
> explicit version checks, but it won't use features that are supported.
>
I addressed that in the email I sent afterwards:
"""
Note that:
- assume_aligned came with gcc 4.9
- no_sanitize_address came with gcc 4.8
So if we feel it is important to have them there (before gcc 5), we
would need here a quick version check here.
"""
The idea is that, in the future, whenever gcc 5 or later is the
minimum version, we just get rid of the #ifdef block without touching
the rest of the code :-)
Cheers,
Miguel
>> > +
>> > +/*
>> > + * __assume_aligned(n, k): Tell the optimizer that the returned
>> > + * pointer can be assumed to be k modulo n. The second argument is
>> > + * optional (default 0), so we use a variadic macro to make the
>> > + * shorthand.
>> > + *
>> > + * Beware: Do not apply this to functions which may return
>> > + * ERR_PTRs. Also, it is probably unwise to apply it to functions
>> > + * returning extra information in the low bits (but in that case the
>> > + * compiler should see some alignment anyway, when the return value is
>> > + * massaged by 'flags = ptr & 3; ptr &= ~3;').
>> > + */
>> > +#if __has_attribute(assume_aligned)
>> > +#define __assume_aligned(a, ...) __attribute__((assume_aligned(a, ##
>> > __VA_ARGS__)))
>> > +#else
>> > +#define __assume_aligned(a, ...)
>> > +#endif
>> > +
>> > +/*
>> > + * Mark structures as requiring designated initializers.
>> > + * https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html
>> > + */
>> > +#if __has_attribute(designated_init)
>> > +#define __designated_init __attribute__((designated_init))
>> > +#else
>> > +#define __designated_init
>> > +#endif
>> > +
>> > +/*
>> > + * When used with Link Time Optimization, gcc can optimize away C
>> > functions or
>> > + * variables which are referenced only from assembly code. __visible
>> > tells the
>> > + * optimizer that something else uses this function or variable, thus
>> > preventing
>> > + * this.
>> > + */
>> > +#if __has_attribute(externally_visible)
>> > +#define __visible __attribute__((externally_visible))
>> > +#else
>> > +#define __visible
>> > +#endif
>> > +
>> > +/* Mark a function definition as prohibited from being cloned. */
>> > +#if __has_attribute(noclone) && __has_attribute(optimize)
>> > +#define __noclone __attribute__((noclone, optimize("no-tracer")))
>> > +#else
>> > +#define __noclone
>> > +#endif
>> > +
>> > +/*
>> > + * Tell the compiler that address safety instrumentation (KASAN)
>> > + * should not be applied to that function.
>> > + * Conflicts with inlining:
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
>> > + */
>> > +#if __has_attribute(no_sanitize_address)
>> > +#define __no_sanitize_address __attribute__((no_sanitize_address))
>> > +#else
>> > +#define __no_sanitize_address
>> > +#endif
>> > +
>> > +#endif /* __LINUX_COMPILER_ATTRIBUTES_H */
>> > diff --git a/include/linux/compiler_types.h
>> > b/include/linux/compiler_types.h
>> > index 3525c179698c..8cd622bedec4 100644
>> > --- a/include/linux/compiler_types.h
>> > +++ b/include/linux/compiler_types.h
>> > @@ -54,6 +54,9 @@ extern void __chk_io_ptr(const volatile void __iomem *);
>> >
>> > #ifdef __KERNEL__
>> >
>> > +/* Attributes */
>> > +#include
>> > +
>> > /* Compiler specific macros. */
>> > #ifdef __clang__
>> > #include
>> > @@ -78,12 +81,6 @@ extern void __chk_io_ptr(const volatile void __iomem *);
>> > #include
>> > #endif
>> >
>> > -/*
>> > - * Generic compiler-independent macros required for kernel
>> > - * build go below this comment. Actual compiler/compiler version
>> > - * specific implementations come from the above header files
>> > - */
>> > -
>> > struct ftrace_branch_data {
>> > const char *func;
>> > const char *file;
>> > @@ -119,10 +116,6 @@ struct ftrace_likely_data {
>> > * compilers. We don't consider that to be an error, so set them to
>> > nothing.
>> > * For example, some of them are
Re: [PATCH] include/linux/compiler*.h: Use feature checking instead of version checks for attributes
Hi Nick,
On Mon, Aug 27, 2018 at 7:48 PM, Nick Desaulniers
wrote:
> On Mon, Aug 27, 2018 at 10:43 AM Nick Desaulniers
>> > +
>> > +/*
>> > + * Optional attributes: your compiler may or may not support them.
>> > + *
>> > + * To check for them, we use __has_attribute, which is supported on gcc
>> > >= 5,
>> > + * clang >= 2.9 and icc >= 17. In the meantime, to support 4.6 <= gcc < 5,
>> > + * we implement it by hand.
>> > + */
>> > +#ifndef __has_attribute
>> > +#define __has_attribute(x) __GCC46_has_attribute_##x
>> > +#define __GCC46_has_attribute_assume_aligned 0
>> > +#define __GCC46_has_attribute_designated_init 0
>> > +#define __GCC46_has_attribute_externally_visible 1
>> > +#define __GCC46_has_attribute_noclone 1
>> > +#define __GCC46_has_attribute_optimize 1
>> > +#define __GCC46_has_attribute_no_sanitize_address 0
>> > +#endif
>
> And a follow up; I'm trying to understand what will happen in the case
> of say gcc 4.9 here. Were any of these supported between gcc 4.6 and
> 5.0? If so, then this code will not use them. It's simpler than
> explicit version checks, but it won't use features that are supported.
>
I addressed that in the email I sent afterwards:
"""
Note that:
- assume_aligned came with gcc 4.9
- no_sanitize_address came with gcc 4.8
So if we feel it is important to have them there (before gcc 5), we
would need here a quick version check here.
"""
The idea is that, in the future, whenever gcc 5 or later is the
minimum version, we just get rid of the #ifdef block without touching
the rest of the code :-)
Cheers,
Miguel
>> > +
>> > +/*
>> > + * __assume_aligned(n, k): Tell the optimizer that the returned
>> > + * pointer can be assumed to be k modulo n. The second argument is
>> > + * optional (default 0), so we use a variadic macro to make the
>> > + * shorthand.
>> > + *
>> > + * Beware: Do not apply this to functions which may return
>> > + * ERR_PTRs. Also, it is probably unwise to apply it to functions
>> > + * returning extra information in the low bits (but in that case the
>> > + * compiler should see some alignment anyway, when the return value is
>> > + * massaged by 'flags = ptr & 3; ptr &= ~3;').
>> > + */
>> > +#if __has_attribute(assume_aligned)
>> > +#define __assume_aligned(a, ...) __attribute__((assume_aligned(a, ##
>> > __VA_ARGS__)))
>> > +#else
>> > +#define __assume_aligned(a, ...)
>> > +#endif
>> > +
>> > +/*
>> > + * Mark structures as requiring designated initializers.
>> > + * https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html
>> > + */
>> > +#if __has_attribute(designated_init)
>> > +#define __designated_init __attribute__((designated_init))
>> > +#else
>> > +#define __designated_init
>> > +#endif
>> > +
>> > +/*
>> > + * When used with Link Time Optimization, gcc can optimize away C
>> > functions or
>> > + * variables which are referenced only from assembly code. __visible
>> > tells the
>> > + * optimizer that something else uses this function or variable, thus
>> > preventing
>> > + * this.
>> > + */
>> > +#if __has_attribute(externally_visible)
>> > +#define __visible __attribute__((externally_visible))
>> > +#else
>> > +#define __visible
>> > +#endif
>> > +
>> > +/* Mark a function definition as prohibited from being cloned. */
>> > +#if __has_attribute(noclone) && __has_attribute(optimize)
>> > +#define __noclone __attribute__((noclone, optimize("no-tracer")))
>> > +#else
>> > +#define __noclone
>> > +#endif
>> > +
>> > +/*
>> > + * Tell the compiler that address safety instrumentation (KASAN)
>> > + * should not be applied to that function.
>> > + * Conflicts with inlining:
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
>> > + */
>> > +#if __has_attribute(no_sanitize_address)
>> > +#define __no_sanitize_address __attribute__((no_sanitize_address))
>> > +#else
>> > +#define __no_sanitize_address
>> > +#endif
>> > +
>> > +#endif /* __LINUX_COMPILER_ATTRIBUTES_H */
>> > diff --git a/include/linux/compiler_types.h
>> > b/include/linux/compiler_types.h
>> > index 3525c179698c..8cd622bedec4 100644
>> > --- a/include/linux/compiler_types.h
>> > +++ b/include/linux/compiler_types.h
>> > @@ -54,6 +54,9 @@ extern void __chk_io_ptr(const volatile void __iomem *);
>> >
>> > #ifdef __KERNEL__
>> >
>> > +/* Attributes */
>> > +#include
>> > +
>> > /* Compiler specific macros. */
>> > #ifdef __clang__
>> > #include
>> > @@ -78,12 +81,6 @@ extern void __chk_io_ptr(const volatile void __iomem *);
>> > #include
>> > #endif
>> >
>> > -/*
>> > - * Generic compiler-independent macros required for kernel
>> > - * build go below this comment. Actual compiler/compiler version
>> > - * specific implementations come from the above header files
>> > - */
>> > -
>> > struct ftrace_branch_data {
>> > const char *func;
>> > const char *file;
>> > @@ -119,10 +116,6 @@ struct ftrace_likely_data {
>> > * compilers. We don't consider that to be an error, so set them to
>> > nothing.
>> > * For example, some of them are
Re: [PATCH] include/linux/compiler*.h: Use feature checking instead of version checks for attributes
Hi Nick,
On Mon, Aug 27, 2018 at 7:43 PM, Nick Desaulniers
wrote:
> On Sun, Aug 26, 2018 at 10:58 AM Miguel Ojeda
> wrote:
>>
>> Instead of using version checks per-compiler to define (or not) each
>> attribute,
>> use __has_attribute to test for them, following the cleanup started with
>> commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually
>> exclusive").
>>
>> All the attributes that are fairly common/standard (i.e. those that do not
>> require extra logic to define them) have been moved to a new file
>> include/linux/compiler_attributes.h. The attributes have been sorted
>> and divided between "required" and "optional".
>
> Nice! Thanks Miguel. Regarding sorting, I'm happy with that. In
> fact, some of the comments can be removed IMO, as the attributes have
> common definitions in the docs (maybe an added link to the gcc and
> clang attribute docs at the top of the file rather than per attribute
> comments).
Thanks for the review!
I thought about that, although there isn't a single page with them in
GCC (we could group them by type though: function ones, variable
ones... and then link to those). On the other hand, maybe writing a
Doc/ file is better and allows us to write as much as one would like
about each of them (and a link to each page compiler's page about it,
etc.). I think in the end the Doc/ file might be the best, in order
not to crowd the header.
>
>>
>> Further, attributes that are already supported in gcc >= 4.6 and recent clang
>> were simply made to be required (instead of testing for them):
>> * always_inline
>> * const (pure was already "required", by the way)
>> * gnu_inline
>
> There's an important test for gnu_inline that isn't checking that it's
> supported, but rather what the implicit behavior is depending on which
> C standard is being used. It's important not to remove that.
Hm... I actually thought it was not available at some point before 4.6
and removed the #ifdef. The comment even says it is featuring
detecting it so that the old GCC inlining is used; but it shouldn't
matter if you always use it, no?
I just went looking for more info in d03db2bc2 ("compiler-gcc.h: Add
__attribute__((gnu_inline)) to all inline declarations") and if I
understood the commit message, the problem is compiling with implicit
new standard in newer compilers which trigger the C90 behavior, while
we need the old one --- but if we use gnu_inline, we are getting it
regardless.
I am sure I am missing something, but I think a clarification is
needed (and in the code comment as well) -- a bit off-topic, anyway.
[Also, I wouldn't define an attribute or not depending on some other
condition. I would, instead, define something some other symbol with
that logic (i.e. instead of using "__gnu_inline", because that is
lying -- it is not using the attribute even if the compiler supports
it).]
>
>>
>> Finally, some other bits were cleaned up in the process:
>> * __optimize: removed (unused in the whole kernel tree)
>
> A+ for removing dead code. I also don't see it used anywhere.
>
>> * __must_be_array: removed from -gcc and -clang (identical), moved to
>> _types
>
> Yep, uses a builtin (we should add guards for that, later, in a
> similar style change that guards the use of builtins). Looks good.
>
>> (it depends on the unconditionally used __builtin_types_compatible_p
>> * Removes unneeded underscores on the attributes' names
>
> That doesn't sound right, but lets see what you mean by that.
Some attributes used the __name__ syntax (i.e. inside the double
parenthesis), others didn't. I simplified by removing all the extra
underscores.
>
>>
>> There are some things that can be further cleaned up afterwards:
>> * __attribute_const__: rename to __const
>
> This doesn't look correct to me; the kernel is full of call sites for
> __attribute_const__. You can't rename the definition without renaming
Of course it is full of use sites! That is why I said it is a possible
cleanup for *afterwards* this patch :-)
> all of the call sites (and that would be too big a change for this
> patch, IMO). Skip the rename, and it also looks like you just removed
> it outright (Oops).
Not sure what you mean by this (?). The attribute is still there unchanged.
>
>> * __noretpoline: avoid checking for defined(__notrepoline)
>> * __compiletime_warning/error: they are in two different places,
>> -gcc and compiler.h.
>> * sparse' attributes could potentially go into the end of attributes.h
>> too (as another separate section).
>>
>> Compile-tested an x86 allmodconfig for a while with gcc 8.2.0 and 4.6.4.
>
> It's important to test changes to compiler-clang.h with clang. ;)
I would agree if the clang build wasn't broken to begin with. ;)
>
>>
>> Cc: Eli Friedman
>> Cc: Christopher Li
>> Cc: Kees Cook
>> Cc: Ingo Molnar
>> Cc: Geert Uytterhoeven
>> Cc: Arnd Bergmann
>> Cc: Greg Kroah-Hartman
>> Cc: Masahiro Yamada
>> Cc: Joe Perches
>> Cc: Dominique
Re: [PATCH] include/linux/compiler*.h: Use feature checking instead of version checks for attributes
Hi Nick,
On Mon, Aug 27, 2018 at 7:43 PM, Nick Desaulniers
wrote:
> On Sun, Aug 26, 2018 at 10:58 AM Miguel Ojeda
> wrote:
>>
>> Instead of using version checks per-compiler to define (or not) each
>> attribute,
>> use __has_attribute to test for them, following the cleanup started with
>> commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually
>> exclusive").
>>
>> All the attributes that are fairly common/standard (i.e. those that do not
>> require extra logic to define them) have been moved to a new file
>> include/linux/compiler_attributes.h. The attributes have been sorted
>> and divided between "required" and "optional".
>
> Nice! Thanks Miguel. Regarding sorting, I'm happy with that. In
> fact, some of the comments can be removed IMO, as the attributes have
> common definitions in the docs (maybe an added link to the gcc and
> clang attribute docs at the top of the file rather than per attribute
> comments).
Thanks for the review!
I thought about that, although there isn't a single page with them in
GCC (we could group them by type though: function ones, variable
ones... and then link to those). On the other hand, maybe writing a
Doc/ file is better and allows us to write as much as one would like
about each of them (and a link to each page compiler's page about it,
etc.). I think in the end the Doc/ file might be the best, in order
not to crowd the header.
>
>>
>> Further, attributes that are already supported in gcc >= 4.6 and recent clang
>> were simply made to be required (instead of testing for them):
>> * always_inline
>> * const (pure was already "required", by the way)
>> * gnu_inline
>
> There's an important test for gnu_inline that isn't checking that it's
> supported, but rather what the implicit behavior is depending on which
> C standard is being used. It's important not to remove that.
Hm... I actually thought it was not available at some point before 4.6
and removed the #ifdef. The comment even says it is featuring
detecting it so that the old GCC inlining is used; but it shouldn't
matter if you always use it, no?
I just went looking for more info in d03db2bc2 ("compiler-gcc.h: Add
__attribute__((gnu_inline)) to all inline declarations") and if I
understood the commit message, the problem is compiling with implicit
new standard in newer compilers which trigger the C90 behavior, while
we need the old one --- but if we use gnu_inline, we are getting it
regardless.
I am sure I am missing something, but I think a clarification is
needed (and in the code comment as well) -- a bit off-topic, anyway.
[Also, I wouldn't define an attribute or not depending on some other
condition. I would, instead, define something some other symbol with
that logic (i.e. instead of using "__gnu_inline", because that is
lying -- it is not using the attribute even if the compiler supports
it).]
>
>>
>> Finally, some other bits were cleaned up in the process:
>> * __optimize: removed (unused in the whole kernel tree)
>
> A+ for removing dead code. I also don't see it used anywhere.
>
>> * __must_be_array: removed from -gcc and -clang (identical), moved to
>> _types
>
> Yep, uses a builtin (we should add guards for that, later, in a
> similar style change that guards the use of builtins). Looks good.
>
>> (it depends on the unconditionally used __builtin_types_compatible_p
>> * Removes unneeded underscores on the attributes' names
>
> That doesn't sound right, but lets see what you mean by that.
Some attributes used the __name__ syntax (i.e. inside the double
parenthesis), others didn't. I simplified by removing all the extra
underscores.
>
>>
>> There are some things that can be further cleaned up afterwards:
>> * __attribute_const__: rename to __const
>
> This doesn't look correct to me; the kernel is full of call sites for
> __attribute_const__. You can't rename the definition without renaming
Of course it is full of use sites! That is why I said it is a possible
cleanup for *afterwards* this patch :-)
> all of the call sites (and that would be too big a change for this
> patch, IMO). Skip the rename, and it also looks like you just removed
> it outright (Oops).
Not sure what you mean by this (?). The attribute is still there unchanged.
>
>> * __noretpoline: avoid checking for defined(__notrepoline)
>> * __compiletime_warning/error: they are in two different places,
>> -gcc and compiler.h.
>> * sparse' attributes could potentially go into the end of attributes.h
>> too (as another separate section).
>>
>> Compile-tested an x86 allmodconfig for a while with gcc 8.2.0 and 4.6.4.
>
> It's important to test changes to compiler-clang.h with clang. ;)
I would agree if the clang build wasn't broken to begin with. ;)
>
>>
>> Cc: Eli Friedman
>> Cc: Christopher Li
>> Cc: Kees Cook
>> Cc: Ingo Molnar
>> Cc: Geert Uytterhoeven
>> Cc: Arnd Bergmann
>> Cc: Greg Kroah-Hartman
>> Cc: Masahiro Yamada
>> Cc: Joe Perches
>> Cc: Dominique
Re: [PATCH] include/linux/compiler*.h: Use feature checking instead of version checks for attributes
On Mon, Aug 27, 2018 at 10:43 AM Nick Desaulniers
wrote:
>
> On Sun, Aug 26, 2018 at 10:58 AM Miguel Ojeda
> wrote:
> >
> > Instead of using version checks per-compiler to define (or not) each
> > attribute,
> > use __has_attribute to test for them, following the cleanup started with
> > commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually
> > exclusive").
> >
> > All the attributes that are fairly common/standard (i.e. those that do not
> > require extra logic to define them) have been moved to a new file
> > include/linux/compiler_attributes.h. The attributes have been sorted
> > and divided between "required" and "optional".
>
> Nice! Thanks Miguel. Regarding sorting, I'm happy with that. In
> fact, some of the comments can be removed IMO, as the attributes have
> common definitions in the docs (maybe an added link to the gcc and
> clang attribute docs at the top of the file rather than per attribute
> comments).
>
> >
> > Further, attributes that are already supported in gcc >= 4.6 and recent
> > clang
> > were simply made to be required (instead of testing for them):
> > * always_inline
> > * const (pure was already "required", by the way)
> > * gnu_inline
>
> There's an important test for gnu_inline that isn't checking that it's
> supported, but rather what the implicit behavior is depending on which
> C standard is being used. It's important not to remove that.
>
> >
> > Finally, some other bits were cleaned up in the process:
> > * __optimize: removed (unused in the whole kernel tree)
>
> A+ for removing dead code. I also don't see it used anywhere.
>
> > * __must_be_array: removed from -gcc and -clang (identical), moved to
> > _types
>
> Yep, uses a builtin (we should add guards for that, later, in a
> similar style change that guards the use of builtins). Looks good.
>
> > (it depends on the unconditionally used __builtin_types_compatible_p
> > * Removes unneeded underscores on the attributes' names
>
> That doesn't sound right, but lets see what you mean by that.
>
> >
> > There are some things that can be further cleaned up afterwards:
> > * __attribute_const__: rename to __const
>
> This doesn't look correct to me; the kernel is full of call sites for
> __attribute_const__. You can't rename the definition without renaming
> all of the call sites (and that would be too big a change for this
> patch, IMO). Skip the rename, and it also looks like you just removed
> it outright (Oops).
>
> > * __noretpoline: avoid checking for defined(__notrepoline)
> > * __compiletime_warning/error: they are in two different places,
> > -gcc and compiler.h.
> > * sparse' attributes could potentially go into the end of attributes.h
> > too (as another separate section).
> >
> > Compile-tested an x86 allmodconfig for a while with gcc 8.2.0 and 4.6.4.
>
> It's important to test changes to compiler-clang.h with clang. ;)
>
> >
> > Cc: Eli Friedman
> > Cc: Christopher Li
> > Cc: Kees Cook
> > Cc: Ingo Molnar
> > Cc: Geert Uytterhoeven
> > Cc: Arnd Bergmann
> > Cc: Greg Kroah-Hartman
> > Cc: Masahiro Yamada
> > Cc: Joe Perches
> > Cc: Dominique Martinet
> > Cc: Nick Desaulniers
> > Cc: Linus Torvalds
> > Signed-off-by: Miguel Ojeda
> > ---
> > *Seems* to work, but note that I did not finish the entire allmodconfig :)
> >
> > A few things could be splitted into their own patch, but I kept it
> > as one for simplicity for a first review.
> >
> > These files are becoming no-headaches-readable again, yay.
>
> A+
>
> >
> > include/linux/compiler-clang.h | 5 --
> > include/linux/compiler-gcc.h| 60
> > include/linux/compiler-intel.h | 6 --
> > include/linux/compiler.h| 4 --
> > include/linux/compiler_attributes.h | 105
> > include/linux/compiler_types.h | 91
> > 6 files changed, 118 insertions(+), 153 deletions(-)
> > create mode 100644 include/linux/compiler_attributes.h
> >
> > diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
> > index b1ce500fe8b3..3e7dafb3ea80 100644
> > --- a/include/linux/compiler-clang.h
> > +++ b/include/linux/compiler-clang.h
> > @@ -21,8 +21,6 @@
> > #define __SANITIZE_ADDRESS__
> > #endif
> >
> > -#define __no_sanitize_address __attribute__((no_sanitize("address")))
> > -
> > /*
> > * Not all versions of clang implement the the type-generic versions
> > * of the builtin overflow checkers. Fortunately, clang implements
> > @@ -41,6 +39,3 @@
> > * compilers, like ICC.
> > */
> > #define barrier() __asm__ __volatile__("" : : : "memory")
> > -#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
> > -#define __assume_aligned(a, ...) \
> > - __attribute__((__assume_aligned__(a, ## __VA_ARGS__)))
> > diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> > index 763bbad1e258..dde3daae6287 100644
> > ---
Re: [PATCH] include/linux/compiler*.h: Use feature checking instead of version checks for attributes
On Mon, Aug 27, 2018 at 10:43 AM Nick Desaulniers
wrote:
>
> On Sun, Aug 26, 2018 at 10:58 AM Miguel Ojeda
> wrote:
> >
> > Instead of using version checks per-compiler to define (or not) each
> > attribute,
> > use __has_attribute to test for them, following the cleanup started with
> > commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually
> > exclusive").
> >
> > All the attributes that are fairly common/standard (i.e. those that do not
> > require extra logic to define them) have been moved to a new file
> > include/linux/compiler_attributes.h. The attributes have been sorted
> > and divided between "required" and "optional".
>
> Nice! Thanks Miguel. Regarding sorting, I'm happy with that. In
> fact, some of the comments can be removed IMO, as the attributes have
> common definitions in the docs (maybe an added link to the gcc and
> clang attribute docs at the top of the file rather than per attribute
> comments).
>
> >
> > Further, attributes that are already supported in gcc >= 4.6 and recent
> > clang
> > were simply made to be required (instead of testing for them):
> > * always_inline
> > * const (pure was already "required", by the way)
> > * gnu_inline
>
> There's an important test for gnu_inline that isn't checking that it's
> supported, but rather what the implicit behavior is depending on which
> C standard is being used. It's important not to remove that.
>
> >
> > Finally, some other bits were cleaned up in the process:
> > * __optimize: removed (unused in the whole kernel tree)
>
> A+ for removing dead code. I also don't see it used anywhere.
>
> > * __must_be_array: removed from -gcc and -clang (identical), moved to
> > _types
>
> Yep, uses a builtin (we should add guards for that, later, in a
> similar style change that guards the use of builtins). Looks good.
>
> > (it depends on the unconditionally used __builtin_types_compatible_p
> > * Removes unneeded underscores on the attributes' names
>
> That doesn't sound right, but lets see what you mean by that.
>
> >
> > There are some things that can be further cleaned up afterwards:
> > * __attribute_const__: rename to __const
>
> This doesn't look correct to me; the kernel is full of call sites for
> __attribute_const__. You can't rename the definition without renaming
> all of the call sites (and that would be too big a change for this
> patch, IMO). Skip the rename, and it also looks like you just removed
> it outright (Oops).
>
> > * __noretpoline: avoid checking for defined(__notrepoline)
> > * __compiletime_warning/error: they are in two different places,
> > -gcc and compiler.h.
> > * sparse' attributes could potentially go into the end of attributes.h
> > too (as another separate section).
> >
> > Compile-tested an x86 allmodconfig for a while with gcc 8.2.0 and 4.6.4.
>
> It's important to test changes to compiler-clang.h with clang. ;)
>
> >
> > Cc: Eli Friedman
> > Cc: Christopher Li
> > Cc: Kees Cook
> > Cc: Ingo Molnar
> > Cc: Geert Uytterhoeven
> > Cc: Arnd Bergmann
> > Cc: Greg Kroah-Hartman
> > Cc: Masahiro Yamada
> > Cc: Joe Perches
> > Cc: Dominique Martinet
> > Cc: Nick Desaulniers
> > Cc: Linus Torvalds
> > Signed-off-by: Miguel Ojeda
> > ---
> > *Seems* to work, but note that I did not finish the entire allmodconfig :)
> >
> > A few things could be splitted into their own patch, but I kept it
> > as one for simplicity for a first review.
> >
> > These files are becoming no-headaches-readable again, yay.
>
> A+
>
> >
> > include/linux/compiler-clang.h | 5 --
> > include/linux/compiler-gcc.h| 60
> > include/linux/compiler-intel.h | 6 --
> > include/linux/compiler.h| 4 --
> > include/linux/compiler_attributes.h | 105
> > include/linux/compiler_types.h | 91
> > 6 files changed, 118 insertions(+), 153 deletions(-)
> > create mode 100644 include/linux/compiler_attributes.h
> >
> > diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
> > index b1ce500fe8b3..3e7dafb3ea80 100644
> > --- a/include/linux/compiler-clang.h
> > +++ b/include/linux/compiler-clang.h
> > @@ -21,8 +21,6 @@
> > #define __SANITIZE_ADDRESS__
> > #endif
> >
> > -#define __no_sanitize_address __attribute__((no_sanitize("address")))
> > -
> > /*
> > * Not all versions of clang implement the the type-generic versions
> > * of the builtin overflow checkers. Fortunately, clang implements
> > @@ -41,6 +39,3 @@
> > * compilers, like ICC.
> > */
> > #define barrier() __asm__ __volatile__("" : : : "memory")
> > -#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
> > -#define __assume_aligned(a, ...) \
> > - __attribute__((__assume_aligned__(a, ## __VA_ARGS__)))
> > diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> > index 763bbad1e258..dde3daae6287 100644
> > ---
Re: [PATCH] include/linux/compiler*.h: Use feature checking instead of version checks for attributes
On Sun, Aug 26, 2018 at 10:58 AM Miguel Ojeda
wrote:
>
> Instead of using version checks per-compiler to define (or not) each
> attribute,
> use __has_attribute to test for them, following the cleanup started with
> commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually
> exclusive").
>
> All the attributes that are fairly common/standard (i.e. those that do not
> require extra logic to define them) have been moved to a new file
> include/linux/compiler_attributes.h. The attributes have been sorted
> and divided between "required" and "optional".
Nice! Thanks Miguel. Regarding sorting, I'm happy with that. In
fact, some of the comments can be removed IMO, as the attributes have
common definitions in the docs (maybe an added link to the gcc and
clang attribute docs at the top of the file rather than per attribute
comments).
>
> Further, attributes that are already supported in gcc >= 4.6 and recent clang
> were simply made to be required (instead of testing for them):
> * always_inline
> * const (pure was already "required", by the way)
> * gnu_inline
There's an important test for gnu_inline that isn't checking that it's
supported, but rather what the implicit behavior is depending on which
C standard is being used. It's important not to remove that.
>
> Finally, some other bits were cleaned up in the process:
> * __optimize: removed (unused in the whole kernel tree)
A+ for removing dead code. I also don't see it used anywhere.
> * __must_be_array: removed from -gcc and -clang (identical), moved to _types
Yep, uses a builtin (we should add guards for that, later, in a
similar style change that guards the use of builtins). Looks good.
> (it depends on the unconditionally used __builtin_types_compatible_p
> * Removes unneeded underscores on the attributes' names
That doesn't sound right, but lets see what you mean by that.
>
> There are some things that can be further cleaned up afterwards:
> * __attribute_const__: rename to __const
This doesn't look correct to me; the kernel is full of call sites for
__attribute_const__. You can't rename the definition without renaming
all of the call sites (and that would be too big a change for this
patch, IMO). Skip the rename, and it also looks like you just removed
it outright (Oops).
> * __noretpoline: avoid checking for defined(__notrepoline)
> * __compiletime_warning/error: they are in two different places,
> -gcc and compiler.h.
> * sparse' attributes could potentially go into the end of attributes.h
> too (as another separate section).
>
> Compile-tested an x86 allmodconfig for a while with gcc 8.2.0 and 4.6.4.
It's important to test changes to compiler-clang.h with clang. ;)
>
> Cc: Eli Friedman
> Cc: Christopher Li
> Cc: Kees Cook
> Cc: Ingo Molnar
> Cc: Geert Uytterhoeven
> Cc: Arnd Bergmann
> Cc: Greg Kroah-Hartman
> Cc: Masahiro Yamada
> Cc: Joe Perches
> Cc: Dominique Martinet
> Cc: Nick Desaulniers
> Cc: Linus Torvalds
> Signed-off-by: Miguel Ojeda
> ---
> *Seems* to work, but note that I did not finish the entire allmodconfig :)
>
> A few things could be splitted into their own patch, but I kept it
> as one for simplicity for a first review.
>
> These files are becoming no-headaches-readable again, yay.
A+
>
> include/linux/compiler-clang.h | 5 --
> include/linux/compiler-gcc.h| 60
> include/linux/compiler-intel.h | 6 --
> include/linux/compiler.h| 4 --
> include/linux/compiler_attributes.h | 105
> include/linux/compiler_types.h | 91
> 6 files changed, 118 insertions(+), 153 deletions(-)
> create mode 100644 include/linux/compiler_attributes.h
>
> diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
> index b1ce500fe8b3..3e7dafb3ea80 100644
> --- a/include/linux/compiler-clang.h
> +++ b/include/linux/compiler-clang.h
> @@ -21,8 +21,6 @@
> #define __SANITIZE_ADDRESS__
> #endif
>
> -#define __no_sanitize_address __attribute__((no_sanitize("address")))
> -
> /*
> * Not all versions of clang implement the the type-generic versions
> * of the builtin overflow checkers. Fortunately, clang implements
> @@ -41,6 +39,3 @@
> * compilers, like ICC.
> */
> #define barrier() __asm__ __volatile__("" : : : "memory")
> -#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
> -#define __assume_aligned(a, ...) \
> - __attribute__((__assume_aligned__(a, ## __VA_ARGS__)))
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index 763bbad1e258..dde3daae6287 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -68,13 +68,6 @@
> */
> #define uninitialized_var(x) x = x
>
> -#ifdef __CHECKER__
> -#define __must_be_array(a) 0
> -#else
> -/* [0] degrades to a pointer: a different type from an array */
> -#define __must_be_array(a)
Re: [PATCH] include/linux/compiler*.h: Use feature checking instead of version checks for attributes
On Sun, Aug 26, 2018 at 10:58 AM Miguel Ojeda
wrote:
>
> Instead of using version checks per-compiler to define (or not) each
> attribute,
> use __has_attribute to test for them, following the cleanup started with
> commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually
> exclusive").
>
> All the attributes that are fairly common/standard (i.e. those that do not
> require extra logic to define them) have been moved to a new file
> include/linux/compiler_attributes.h. The attributes have been sorted
> and divided between "required" and "optional".
Nice! Thanks Miguel. Regarding sorting, I'm happy with that. In
fact, some of the comments can be removed IMO, as the attributes have
common definitions in the docs (maybe an added link to the gcc and
clang attribute docs at the top of the file rather than per attribute
comments).
>
> Further, attributes that are already supported in gcc >= 4.6 and recent clang
> were simply made to be required (instead of testing for them):
> * always_inline
> * const (pure was already "required", by the way)
> * gnu_inline
There's an important test for gnu_inline that isn't checking that it's
supported, but rather what the implicit behavior is depending on which
C standard is being used. It's important not to remove that.
>
> Finally, some other bits were cleaned up in the process:
> * __optimize: removed (unused in the whole kernel tree)
A+ for removing dead code. I also don't see it used anywhere.
> * __must_be_array: removed from -gcc and -clang (identical), moved to _types
Yep, uses a builtin (we should add guards for that, later, in a
similar style change that guards the use of builtins). Looks good.
> (it depends on the unconditionally used __builtin_types_compatible_p
> * Removes unneeded underscores on the attributes' names
That doesn't sound right, but lets see what you mean by that.
>
> There are some things that can be further cleaned up afterwards:
> * __attribute_const__: rename to __const
This doesn't look correct to me; the kernel is full of call sites for
__attribute_const__. You can't rename the definition without renaming
all of the call sites (and that would be too big a change for this
patch, IMO). Skip the rename, and it also looks like you just removed
it outright (Oops).
> * __noretpoline: avoid checking for defined(__notrepoline)
> * __compiletime_warning/error: they are in two different places,
> -gcc and compiler.h.
> * sparse' attributes could potentially go into the end of attributes.h
> too (as another separate section).
>
> Compile-tested an x86 allmodconfig for a while with gcc 8.2.0 and 4.6.4.
It's important to test changes to compiler-clang.h with clang. ;)
>
> Cc: Eli Friedman
> Cc: Christopher Li
> Cc: Kees Cook
> Cc: Ingo Molnar
> Cc: Geert Uytterhoeven
> Cc: Arnd Bergmann
> Cc: Greg Kroah-Hartman
> Cc: Masahiro Yamada
> Cc: Joe Perches
> Cc: Dominique Martinet
> Cc: Nick Desaulniers
> Cc: Linus Torvalds
> Signed-off-by: Miguel Ojeda
> ---
> *Seems* to work, but note that I did not finish the entire allmodconfig :)
>
> A few things could be splitted into their own patch, but I kept it
> as one for simplicity for a first review.
>
> These files are becoming no-headaches-readable again, yay.
A+
>
> include/linux/compiler-clang.h | 5 --
> include/linux/compiler-gcc.h| 60
> include/linux/compiler-intel.h | 6 --
> include/linux/compiler.h| 4 --
> include/linux/compiler_attributes.h | 105
> include/linux/compiler_types.h | 91
> 6 files changed, 118 insertions(+), 153 deletions(-)
> create mode 100644 include/linux/compiler_attributes.h
>
> diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
> index b1ce500fe8b3..3e7dafb3ea80 100644
> --- a/include/linux/compiler-clang.h
> +++ b/include/linux/compiler-clang.h
> @@ -21,8 +21,6 @@
> #define __SANITIZE_ADDRESS__
> #endif
>
> -#define __no_sanitize_address __attribute__((no_sanitize("address")))
> -
> /*
> * Not all versions of clang implement the the type-generic versions
> * of the builtin overflow checkers. Fortunately, clang implements
> @@ -41,6 +39,3 @@
> * compilers, like ICC.
> */
> #define barrier() __asm__ __volatile__("" : : : "memory")
> -#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
> -#define __assume_aligned(a, ...) \
> - __attribute__((__assume_aligned__(a, ## __VA_ARGS__)))
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index 763bbad1e258..dde3daae6287 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -68,13 +68,6 @@
> */
> #define uninitialized_var(x) x = x
>
> -#ifdef __CHECKER__
> -#define __must_be_array(a) 0
> -#else
> -/* [0] degrades to a pointer: a different type from an array */
> -#define __must_be_array(a)
Re: [PATCH] include/linux/compiler*.h: Use feature checking instead of version checks for attributes
Hi Joe,
On Sun, Aug 26, 2018 at 8:50 PM, Joe Perches wrote:
> On Sun, 2018-08-26 at 19:57 +0200, Miguel Ojeda wrote:
>> Instead of using version checks per-compiler to define (or not) each
>> attribute,
>> use __has_attribute to test for them, following the cleanup started with
>> commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually
>> exclusive").
>
> Very nice. Thank you Miguel.
Thanks!
>
> trivia:
>
> I believe the alphabetic sorting of the required attributes
> makes reading by use a bit difficult and I would prefer that
> various required attributes are sorted by logical use instead.
>
> ie: keep noinline and __always_inline together,
> keep __used and __always_unused together,
> etc...
>
>
Both ways are fine with me --- I sorted them as an attempt to avoid
the file evolving into a mess again in the upcoming years :-)
Half-joking: it may also be a good way to avoid people "guessing" what
the attributes do by name and, instead, consulting the docs (either
the compiler's, or a Doc/ file maybe).
Cheers,
Miguel
Re: [PATCH] include/linux/compiler*.h: Use feature checking instead of version checks for attributes
Hi Joe,
On Sun, Aug 26, 2018 at 8:50 PM, Joe Perches wrote:
> On Sun, 2018-08-26 at 19:57 +0200, Miguel Ojeda wrote:
>> Instead of using version checks per-compiler to define (or not) each
>> attribute,
>> use __has_attribute to test for them, following the cleanup started with
>> commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually
>> exclusive").
>
> Very nice. Thank you Miguel.
Thanks!
>
> trivia:
>
> I believe the alphabetic sorting of the required attributes
> makes reading by use a bit difficult and I would prefer that
> various required attributes are sorted by logical use instead.
>
> ie: keep noinline and __always_inline together,
> keep __used and __always_unused together,
> etc...
>
>
Both ways are fine with me --- I sorted them as an attempt to avoid
the file evolving into a mess again in the upcoming years :-)
Half-joking: it may also be a good way to avoid people "guessing" what
the attributes do by name and, instead, consulting the docs (either
the compiler's, or a Doc/ file maybe).
Cheers,
Miguel
Re: [PATCH] include/linux/compiler*.h: Use feature checking instead of version checks for attributes
On Sun, 2018-08-26 at 19:57 +0200, Miguel Ojeda wrote:
> Instead of using version checks per-compiler to define (or not) each
> attribute,
> use __has_attribute to test for them, following the cleanup started with
> commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually
> exclusive").
Very nice. Thank you Miguel.
trivia:
I believe the alphabetic sorting of the required attributes
makes reading by use a bit difficult and I would prefer that
various required attributes are sorted by logical use instead.
ie: keep noinline and __always_inline together,
keep __used and __always_unused together,
etc...
Re: [PATCH] include/linux/compiler*.h: Use feature checking instead of version checks for attributes
On Sun, 2018-08-26 at 19:57 +0200, Miguel Ojeda wrote:
> Instead of using version checks per-compiler to define (or not) each
> attribute,
> use __has_attribute to test for them, following the cleanup started with
> commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually
> exclusive").
Very nice. Thank you Miguel.
trivia:
I believe the alphabetic sorting of the required attributes
makes reading by use a bit difficult and I would prefer that
various required attributes are sorted by logical use instead.
ie: keep noinline and __always_inline together,
keep __used and __always_unused together,
etc...
Re: [PATCH] include/linux/compiler*.h: Use feature checking instead of version checks for attributes
Hi, A couple of extra notes on my patch. On Sun, Aug 26, 2018 at 7:57 PM, Miguel Ojeda wrote: > +/* > + * Optional attributes: your compiler may or may not support them. > + * > + * To check for them, we use __has_attribute, which is supported on gcc >= 5, > + * clang >= 2.9 and icc >= 17. In the meantime, to support 4.6 <= gcc < 5, > + * we implement it by hand. > + */ > +#ifndef __has_attribute > +#define __has_attribute(x) __GCC46_has_attribute_##x > +#define __GCC46_has_attribute_assume_aligned 0 > +#define __GCC46_has_attribute_designated_init 0 > +#define __GCC46_has_attribute_externally_visible 1 > +#define __GCC46_has_attribute_noclone 1 > +#define __GCC46_has_attribute_optimize 1 > +#define __GCC46_has_attribute_no_sanitize_address 0 Note that: - assume_aligned came with gcc 4.9 - no_sanitize_address came with gcc 4.8 So if we feel it is important to have them there (before gcc 5), we would need here a quick version check here. > +#endif > + > +/* > + * __assume_aligned(n, k): Tell the optimizer that the returned > + * pointer can be assumed to be k modulo n. The second argument is > + * optional (default 0), so we use a variadic macro to make the > + * shorthand. > + * > + * Beware: Do not apply this to functions which may return > + * ERR_PTRs. Also, it is probably unwise to apply it to functions > + * returning extra information in the low bits (but in that case the > + * compiler should see some alignment anyway, when the return value is > + * massaged by 'flags = ptr & 3; ptr &= ~3;'). > + */ > +#if __has_attribute(assume_aligned) > +#define __assume_aligned(a, ...) __attribute__((assume_aligned(a, ## > __VA_ARGS__))) > +#else > +#define __assume_aligned(a, ...) > +#endif Beforehand, these were !defined(__CHECKER__). I am not sure if sparse complains too much about it. Maybe sparse could learn __has_attribute. Cheers, Miguel
Re: [PATCH] include/linux/compiler*.h: Use feature checking instead of version checks for attributes
Hi, A couple of extra notes on my patch. On Sun, Aug 26, 2018 at 7:57 PM, Miguel Ojeda wrote: > +/* > + * Optional attributes: your compiler may or may not support them. > + * > + * To check for them, we use __has_attribute, which is supported on gcc >= 5, > + * clang >= 2.9 and icc >= 17. In the meantime, to support 4.6 <= gcc < 5, > + * we implement it by hand. > + */ > +#ifndef __has_attribute > +#define __has_attribute(x) __GCC46_has_attribute_##x > +#define __GCC46_has_attribute_assume_aligned 0 > +#define __GCC46_has_attribute_designated_init 0 > +#define __GCC46_has_attribute_externally_visible 1 > +#define __GCC46_has_attribute_noclone 1 > +#define __GCC46_has_attribute_optimize 1 > +#define __GCC46_has_attribute_no_sanitize_address 0 Note that: - assume_aligned came with gcc 4.9 - no_sanitize_address came with gcc 4.8 So if we feel it is important to have them there (before gcc 5), we would need here a quick version check here. > +#endif > + > +/* > + * __assume_aligned(n, k): Tell the optimizer that the returned > + * pointer can be assumed to be k modulo n. The second argument is > + * optional (default 0), so we use a variadic macro to make the > + * shorthand. > + * > + * Beware: Do not apply this to functions which may return > + * ERR_PTRs. Also, it is probably unwise to apply it to functions > + * returning extra information in the low bits (but in that case the > + * compiler should see some alignment anyway, when the return value is > + * massaged by 'flags = ptr & 3; ptr &= ~3;'). > + */ > +#if __has_attribute(assume_aligned) > +#define __assume_aligned(a, ...) __attribute__((assume_aligned(a, ## > __VA_ARGS__))) > +#else > +#define __assume_aligned(a, ...) > +#endif Beforehand, these were !defined(__CHECKER__). I am not sure if sparse complains too much about it. Maybe sparse could learn __has_attribute. Cheers, Miguel
