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: <Mz-kWneLsFvKbBcTaGnC2xMA2U55fINzOJqmMRMumrtTaeHW40WfS5rYUjF_71aoXG56jSHo0vJ0oRPNoCrxpE_oIr7mmnK6fg9dFC_J9hk=@protonmail.com>
Date: Tue, 25 Jun 2024 02:06:54 +0000
From: Koakuma <koachan@...tonmail.com>
To: John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
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 Adrian~

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.

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.

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.

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