On Mon, Jul 31, 2023 at 11:05:11PM +0800, Mingzheng Xing wrote:
Binutils-2.38 and GCC-12.1.0 bumped[0][1] the default ISA spec to the newer 20191213 version which moves some instructions from the I extension to the Zicsr and Zifencei extensions. So if one of the binutils and GCC exceeds that version, we should explicitly specifying Zicsr and Zifencei via -march to cope with the new changes. but this only occurs when binutils >= 2.36 and GCC >= 11.1.0. It's a different story when binutils < 2.36.
binutils-2.36 supports the Zifencei extension[2] and splits Zifencei and Zicsr from I[3]. GCC-11.1.0 is particular[4] because it add support Zicsr and Zifencei extension for -march. binutils-2.35 does not support the Zifencei extension, and does not need to specify Zicsr and Zifencei when working with GCC >= 12.1.0.
To make our lives easier, let's relax the check to binutils >= 2.36 in CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI. For the other two cases, where clang < 17 or GCC < 11.1.0, we will deal with them in CONFIG_TOOLCHAIN_NEEDS_OLD_ISA_SPEC.
For more information, please refer to: commit 6df2a016c0c8 ("riscv: fix build with binutils 2.38") commit e89c2e815e76 ("riscv: Handle zicsr/zifencei issues between clang and binutils") Link: https://sourceware.org/git/?p=binutils-gdb.git%3Ba=commit%3Bh=aed44286efa8ae... [0] Link: https://gcc.gnu.org/git/?p=gcc.git%3Ba=commit%3Bh=98416dbb0a62579d4a7a4a76ba... [1] Link: https://sourceware.org/git/?p=binutils-gdb.git%3Ba=commit%3Bh=5a1b31e1e1cee6... [2] Link: https://sourceware.org/git/?p=binutils-gdb.git%3Ba=commit%3Bh=729a53530e8697... [3] Link: https://gcc.gnu.org/git/?p=gcc.git%3Ba=commit%3Bh=b03be74bad08c382da47e04800... [4] Link: https://lore.kernel.org/all/20230308220842.1231003-1-conor@kernel.org Link: https://lore.kernel.org/all/20230223220546.52879-1-conor@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Mingzheng Xing xingmingzheng@iscas.ac.cn
This looks good to me now, thanks! Hopefully the next time we look at this code is removing support for binutils 2.35 :) Reviewed-by: Conor Dooley conor.dooley@microchip.com
Cheers, Conor.