On Wed, 25 Mar 2020 at 12:41, Mark Brown <broonie@xxxxxxxxxx> wrote: > > Currently several assembler files override the default architecture to > enable extensions in order to allow them to implement optimised routines > for systems with those extensions. Since inserting BTI landing pads into > assembler functions will require us to change the default architecture we > need a way to enable extensions without hard coding the architecture. > The assembler has the .arch_extension feature but this was introduced > for arm64 in gas 2.26 which is too modern for us to rely on it. > > We could just update the base architecture used by these assembler files > but this would mean the assembler would no longer catch attempts to use > newer instructions so instead introduce a macro which sets the default > architecture centrally. Doing this will also make our use of .arch and > .cpu to select the base architecture more consistent. > > Mark Brown (3): > arm64: asm: Provide macro to control enabling architecture extensions > arm64: lib: Use ARM64_EXTENSIONS() > arm64: crypto: Use ARM64_EXTENSIONS() > Hi Mark, 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) > arch/arm64/crypto/aes-ce-ccm-core.S | 3 ++- > arch/arm64/crypto/aes-ce-core.S | 2 +- > arch/arm64/crypto/aes-ce.S | 2 +- > arch/arm64/crypto/crct10dif-ce-core.S | 3 ++- > arch/arm64/crypto/ghash-ce-core.S | 3 ++- > arch/arm64/crypto/sha1-ce-core.S | 3 ++- > arch/arm64/crypto/sha2-ce-core.S | 3 ++- > arch/arm64/include/asm/linkage.h | 6 ++++++ > arch/arm64/lib/crc32.S | 2 +- > 9 files changed, 19 insertions(+), 8 deletions(-) > > -- > 2.20.1 >
