lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 1 Sep 2018 16:17:47 +0200
From:   Dominique Martinet <asmadeus@...ewreck.org>
To:     Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Eli Friedman <efriedma@...eaurora.org>,
        Christopher Li <sparse@...isli.org>,
        Kees Cook <keescook@...omium.org>,
        Ingo Molnar <mingo@...nel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Joe Perches <joe@...ches.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>
Subject: Re: [PATCH 7/7] Compiler Attributes: use feature checks instead of
 version checks

Miguel Ojeda wrote on Sat, Sep 01, 2018:
>>> +/*
>>> + * To check for optional attributes, 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 __has_attribute by hand.
>>> + */
>>> +#ifndef __has_attribute
>>> +#define __has_attribute(x) __GCC4_has_attribute_##x
>>> +#define __GCC4_has_attribute_externally_visible 1
>>> +#define __GCC4_has_attribute_noclone 1
>>> +#define __GCC4_has_attribute_optimize 1
>>> +#if __GNUC_MINOR__ >= 8
>>> +#define __GCC4_has_attribute_no_sanitize_address 1
>>> +#endif
>>> +#if __GNUC_MINOR__ >= 9
>>> +#define __GCC4_has_attribute_assume_aligned 1
>>> +#endif
>>> +#endif
>>
>> Hmm, if this is in this file and not compiler-gcc, I am not sure about
>> using GNUC_MINOR without checking the major -- I have no idea what kind
>> of versions e.g. icc will use (or what attributes ancients version of
>> clang or old icc support, actually)
> 
> The idea here is that all non-gcc recent compilers that we may care
> about support __has_attribute,so if we are inside the #ifndef, we
> *have* to be gcc < 5 (see https://godbolt.org/z/NQFdsK).

That really makes me want to have these in compiler-gcc though :)

But I guess I can also understand wanting to include this file as early
as possible, although I do not think any of the compiler-specific
headers use any of this they could eventually want to override something
from it at some point... Leaving it as an open question, feel free to do
as you prefer here.


> By the way, do you know if there are some public docs on the
> attributes supported by icc that we can link to? I couldn't find
> anything in a quick search, both in google and in the icc's
> "Compatibility" pages...

I'm honestly not using icc much, I just have access to machines where it
is installed...
Actually, now I'm looking there is some html documentation installed
along with icc, but it does not seem complete; instead it points to
software.intel.com ... which has _some_ documentation on attributes, but
is missing a _lot_ of them, see :
https://software.intel.com/en-us/cpp-compiler-18.0-developer-guide-and-reference-attributes

I saw that a lot of these attributes were defined as #pragma first for
icc and had hoped to see something like 'alternative forms' in the
pragma documentations but there does not seem to be anything there
either... Afraid I won't be of much help there.



(from another reply)
> Because of that logic, I tried to simplify as much as possible all
> existing things (e.g. assume_aligned by removing __CHECKER__) so that
> they could be moved to compiler_attributes.h. In a way,
> compiler_attributes.h defines some extensions to the C language that
> all code could use anywhere (actually whether we can move them out of
> __KERNEL__ etc. is another question)

(very good question, though! Figuring out how to share these with the
tools/include/linux/compiler* instead of having an old copy would be a
good start... For another patchset though)

-- 
Dominique

Powered by blists - more mailing lists