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] [day] [month] [year] [list]
Date: Tue, 25 Jun 2024 16:37:08 +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:
> 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].

I am using the version included in Oracle Studio 12.6, and it seems
that it always emit a EM_SPARC32PLUS type for 32-bit objects.

The documentation for the -xarch also states that even when using
the most generic target (`sparc`), it only supports emitting for V9 ISA
(that is, EM_SPARC32PLUS for 32-bit target):

> sparc
> Compile for the SPARC-V9 ISA.
> Compile for the V9 ISA, but without the Visual Instruction Set (VIS),
> and without other implementation-specific ISA extensions. This option
> enables the compiler to generate code for good performance on
> the V9 ISA.

>From https://docs.oracle.com/cd/E77782_01/html/E77803/cc-1.html

Other versions of the compiler might act differently, but sadly I have
no access to them.

> 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.

Hmm, so I just found out after some digging that while `-m32 -mv8plus`
and `-m32 -mcpu=v9` can differ a little, I am not sure if supporting
the full behavior in clang would be worth the effort? I think I can
add `-mv8plus`/`-mno-v8plus` as an alias for `-mcpu=v9`/`-mcpu=v8`, but
any more would probably be too much effort for too little gain?

`-mv8plus` basically allows the compiler to treat the G and O registers
as being 64-bit wide, allowing the compiler to use any of the new
64-bit V9 instructions (e.g. `casx`) as it sees fit. From GCC's docs:

> With `-mv8plus`, GCC generates code for the SPARC-V8+ ABI.
> The difference from the V8 ABI is that the global and out registers
> are considered 64 bits wide. 

https://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html#index-mv8plus

Note that it does not change value passing in parameters or returns
(outgoing parameters still need to be trimmed to 32-bit even though
they are placed in the O registers, for example) so EM_SPARC32PLUS
objects can be freely mixed with EM_SPARC ones.

Also, this seems to be undocumented, but at least from my testing,
`-mv8plus` implies `-mcpu=v9` unless it gets overridden by a later
`-mcpu` flag. So, in theory, it is totally permissible to have
flags like `-m32 -mno-v8plus -mcpu=v9` or `-m32 -mv8plus -mcpu=v8`,
however this will be useless in practice since the combination will
end up disallowing the compiler from using any V9 instructions...

And so far, looking around at kernel sources at least, there seem
to be no need for such kind of flag combinations... though probably
you or others who are more familar could comment on this?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ