On Wed, Mar 25, 2020 at 11:50:38AM +0000, Mark Brown wrote: > On Wed, Mar 25, 2020 at 12:45:11PM +0100, Ard Biesheuvel wrote: > > I don't think this is the right fix. What is wrong with keeping these > > .cpu and .arch directives in the .S files, and simply make > > SYM_FUNC_START() expand to something that includes .arch_extension pac > > or .arch_extension bti when needed? That way, we only use > > .arch_extension when we know the assembler supports it (given that > > .arch_extension support itself should predate BTI or PAC support in > > GAS or Clang) > > Since BTI is a mandatory feature of v8.5 there is no BTI arch_extension, > you can only enable it by moving the base architecture to v8.5. You'd > need to use .arch and that feels likely to find us sharp edges to run > into. For MTE, .arch armv8-a+memtag won't work since this is only available with armv8.5-a. My preference would be to have the highest arch version supported by the kernel in the assembler.h file, i.e. ".arch armv8.5-a" followed by .arch_extension in each .S file, as needed. Forcing .S files to armv8.5 would not cause any problems with the base armv8.0 that the kernel image support since it shouldn't change the opcodes gas generates. The .S files would use alternatives anyway (or simply have code not called). The inline asm is slightly more problematic, especially with the clang builtin assembler which goes in a single pass. But we could do something similar to what we did with the LSE atomics and raising the base of the inline asm to armv8.5 (or 8.6 etc., whatever we need in the future). -- Catalin
