linux-kernel - Re: [PATCH v2 4/6] compiler-gcc.h: add asm

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 linux-cve-announce 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]

Message-ID: <20190907001411.GG9749@gate.crashing.org>
Date:   Fri, 6 Sep 2019 19:14:11 -0500
From:   Segher Boessenkool <segher@...nel.crashing.org>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Jakub Jelinek <jakub@...hat.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "gcc-patches@....gnu.org" <gcc-patches@....gnu.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>
Subject: Re: [PATCH v2 4/6] compiler-gcc.h: add asm_inline definition

On Fri, Sep 06, 2019 at 04:42:58PM -0700, Nick Desaulniers via gcc-patches wrote:
> On Fri, Sep 6, 2019 at 3:56 PM Segher Boessenkool
> <segher@...nel.crashing.org> wrote:
> Oh, I misunderstood.  I see your point.  Define the symbol as a number
> for what level of output flags you support (ie. the __cplusplus
> macro).

That works if history is linear.  I guess with enough effort we can make
that work in most cases (for backports it is a problem, if you want to
support a new feature -- or bugfix! -- you need to support all previous
ones as well...  Distros are going to hate us, too ;-) )

> > > I don't think so.  Can you show me an example codebase that proves me wrong?
> >
> > No, of course not, because we aren't silly enough to implement something
> > like that.
> 
> I still don't think feature detection is worse than version detection
> (until you find your feature broken in a way that forces the use of
> version detection).

*You* bring up version detection.  I don't.  You want some halfway thing,
with some macros that say what version some part of your compiler is.

I say to just detect the feature you want, and if it actually works the
way you want it, etc.

> Just to prove my point about version checks being brittle, it looks
> like Rasmus' version check isn't even right.  GCC supported `asm
> inline` back in the 8.3 release, not 9.1 as in this patch:

Yes, I backported it so that it is available in 7.5, 8.3, and 9.1, so
that more users will have this available sooner.  (7.5 has not been
released yet, but asm inline has been supported in GCC 7 since Jan 2
this year).

> Or was it "broken" until 9.1?  Lord knows, as `asm inline` wasn't in
> any release notes or bug reports I can find:

https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01143.html

It never was accepted, and I dropped the ball.

> Ah, here it is:
> https://github.com/gcc-mirror/gcc/commit/6de46ad5326fc5e6b730a2feb8c62d09c1561f92
> Which looks like the qualifier was added to this page:
> https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html

Sure, it is part of the documentation just fine.  And it works just fine
too, it is a *very* simple feature.  By design.

> I like many of the GNU C extensions, and I want to help support them
> in Clang so that they can be used in more places, but the current
> process (and questions I have when I implement some of them) leaves me
> with the sense that there's probably room for improvement on some of
> these things before they go out the door.
> 
> Segher, next time there's discussion about new C extensions for the
> kernel, can you please include me in the discussions?

You can lurk on gcc-patches@ and/or gcc@?  But I'll try to remember, sure.
Not that I am involved in all such discussions myself, mind.


Segher