|
Message-ID: <20141117133035.GF10829@port70.net> Date: Mon, 17 Nov 2014 14:30:35 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: Arnd Bergmann <arnd@...db.de> Cc: linux-arm-kernel@...ts.infradead.org, Catalin Marinas <catalin.marinas@....com>, Russell King - ARM Linux <linux@....linux.org.uk>, Rich Felker <dalias@...c.org>, Kees Cook <keescook@...omium.org>, "musl@...ts.openwall.com" <musl@...ts.openwall.com>, Andy Lutomirski <luto@...capital.net> Subject: Re: ARM atomics overhaul for musl * Arnd Bergmann <arnd@...db.de> [2014-11-17 13:21:03 +0100]: > On Monday 17 November 2014 11:48:33 Catalin Marinas wrote: > > On Sun, Nov 16, 2014 at 04:33:56PM +0000, Russell King - ARM Linux wrote: > > > On Sun, Nov 16, 2014 at 12:56:56AM -0500, Rich Felker wrote: > > > > Aside from that, the only case among the above that's "right" already > > > > is v7+. Hard-coding the mcr-based barrier on v6 is wrong because it's > > > > > > I don't think it's wrong at all. The instruction isn't going away from > > > ARMv7, because ARMv7 deprecates it, but it _still_ has to be implemented > > > by a CPU conforming to ARMv7. As ARMv7 is going to be the last 32-bit > > > ARM architecture, we aren't going to see the MCR instruction disappearing > > > on 32-bit CPUs. > > > > You are wrong here. ARMv8-A supports 32-bit at all levels. ARMv8-R is > > 32-bit only (and it even has an MMU at EL1). And there is a slight > > chance that we may even see 32-bit only ARMv8-A implementations (I'm not > > really giving a hint and I'm not aware of any but I don't see anything > > preventing this, it's all marketing driven). > > FWIW, both Samsung EXYNOS and Qualcomm Snapdragon SoCs based on Cortex-A53 > have been shipped in 32-bit only devices. > ARMv8-A manual talks about two execution sates: - aarch64 with 64 bit registers and A64 instruction set - aarch32 with 32 bit registers and A32 or T32 instruction sets (i thought an armv8-a cpu must support both but that is not relevant to userspace) for userspace the two states are different architectures so i guess for libc aarch32 backward compatibility is the interesting question (does armv7 instructions, syscalls, elf abi work on aarch32) and how to recognize it when its new features can be used in the libc if aarch32 has cp15 barrier then that is an option for portable binaries and the other approach is runtime dispatch but then libc needs a reliable check for >=armv7
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.