linux-kernel - Re: [PATCH] sparc/build: Make all compiler flags also clang-compatible

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: <e359b140839606b1856c5625669e5b6bd7ebc7eb.camel@physik.fu-berlin.de>
Date: Tue, 25 Jun 2024 09:20:11 +0200
From: John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
To: Koakuma <koachan@...tonmail.com>
Cc: "David S. Miller" <davem@...emloft.net>, Andreas Larsson
 <andreas@...sler.com>, Nathan Chancellor <nathan@...nel.org>, Nick
 Desaulniers <ndesaulniers@...gle.com>, Bill Wendling <morbo@...gle.com>,
 Justin Stitt <justinstitt@...gle.com>, sparclinux@...r.kernel.org, 
 linux-kernel@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [PATCH] sparc/build: Make all compiler flags also
 clang-compatible

Hi Koakuma,

thanks for doing the research work!

On Tue, 2024-06-25 at 02:06 +0000, Koakuma wrote:
> John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de> wrote:
> > V8plus does not use VIS instructions and also has a different ELF machine
> > type, namely EM_SPARC32PLUS instead of EM_SPARCV9 if I understand correctly.
> > 
> > So, we should make sure that the above change will not affect the ELF machine
> > type.
> 
> When assembling with GNU as, there seem to be no control as to what
> machine type we want to emit, as it simply tries to autodetect it based
> on the instruction mix in the assembly code:
> - If there's a V9 instruction inside, then use EM_SPARC32PLUS; and
> - Emit EM_SPARC otherwise.

Interesting. I actually expected some flags being passed to the linker to
enable the EM_SPARC32PLUS machine type.

> This is also the case with GCC - it simply happens that GCC will try
> to emit V9 instructions whenever possible with `-m32 -mv8plus`
> or `-m32 -mcpu=v9` so there's a high chance that the resulting object
> file will be of a EM_SPARC32PLUS type, but this does not seem to be
> a guaranteed behavior.

Would be interesting to find out what Sun's own C/C++ compiler (Sun Studio)
does in this case. I can try to run some tests on Solaris or you can check
out the Solaris machines in the GCC compile farm [1].

> With LLVM's as, we can have finer control of emitted machine type, but
> so far it never sets the type to EM_SPARC32PLUS - for this I have made
> a patch over at https://github.com/llvm/llvm-project/pull/96583.

I just had a brief look - will do the proper review later - and I think
it's the right approach for the time being. However, I am wondering whether
we should add "-mv8plus" to clang as well.

I wondering though whether "-mcpu=v9 -m32" is truly identical to "-mv8plus"
or not.

> As for VIS, GCC (and clang when it eventually supports vectorization)
> should not emit it unless explicitly asked, so I think we are
> in the clear here?
> 
> > With `-mvis`, GCC generates code that takes advantage of
> > the UltraSPARC Visual Instruction Set extensions.
> > The default is `-mno-vis`.
> 
> From https://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html#index-mvis

OK, very good to know. Yes, I think we should be safe here.

Again, thanks a lot for getting this sorted out so quickly!

Adrian

> [1] https://gcc.gnu.org/wiki/CompileFarm

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913