aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/AST/ByteCode/Compiler.cpp
diff options
context:
space:
mode:
authorMing-Yi Lai <ming-yi.lai@mediatek.com>2025-05-14 11:48:59 +0800
committerGitHub <noreply@github.com>2025-05-14 11:48:59 +0800
commit691ca556e04dafa3d755e975ea3432fbfd4ca9ad (patch)
tree7644a49475354c617440d116c6c9815180a6b84f /clang/lib/AST/ByteCode/Compiler.cpp
parent866f1cd6a9146b3ee6ed012c0d90e02bc96d4e16 (diff)
downloadllvm-691ca556e04dafa3d755e975ea3432fbfd4ca9ad.zip
llvm-691ca556e04dafa3d755e975ea3432fbfd4ca9ad.tar.gz
llvm-691ca556e04dafa3d755e975ea3432fbfd4ca9ad.tar.bz2
[RISCV] Emit .note.gnu.property section when Zicfiss-based shadow stack is enabled (#127036)
RISC-V Zicfiss-based shadow stack needs to let the linker/loader know if the binary is built with the mechanism enabled to support proper link-time/load-time management of this feature. The information is encoded as a bit in the `.note.gnu.property` section. This patch implements emitting the section for RISC-V targets when Zicfiss-based shadow stack is enabled. When Clang receives the `-fcf-protection=return` flag, it adds the `hw-shadow-stack` attribute to LLVM functions, and adds a non-zero valued attribute named `cf-protection-return` to the LLVM module it generates. The backend depends on the `hw-shadow-stack` attributes to generate Zicfiss-based shadow stack instructions for each function, but at the module scope, the `cf-protection-return` attribute is a better indication of whether the translation unit is built with Zicfiss-based shadow stack enabled, so this patch emits the `.note.gnu.property` section with the "Zicfiss-based shadow stack" bit toggled on when it sees the `cf-protection-return` attribute.
Diffstat (limited to 'clang/lib/AST/ByteCode/Compiler.cpp')
0 files changed, 0 insertions, 0 deletions