peter.smith accepted this revision.
peter.smith added a comment.
This revision is now accepted and ready to land.
Apologies for the delay LGTM. I think there is a case for setting up the
signature to be target specific, but that could in theory be done on demand
when a target adds a clashing instruction.
================
Comment at: clang/lib/CodeGen/TargetInfo.h:205
getUBSanFunctionSignature(CodeGen::CodeGenModule &CGM) const {
- return nullptr;
+ return llvm::ConstantInt::get(CGM.Int32Ty, 0xc105cafe);
}
----------------
Is it worth making this target specific? Defaulting to 0xc105cafe for all
targets, if that gets allocated in the future on any one target we can change
it without having to test against all other targets.
For example on AArch64 this is is in the decoding space of SME instructions op0
= 0b1 op1 = 0b0000. This may get allocated in the future. Although admittedly
it is likely to be very rare to find a use of a SME instruction at the end of a
function to cause it to get misidentified.
I suspect most targets have an explicit undefined instruction, such as UDF in
AArch64 which is 0x0000???? where ? can be any value. On Arm there two separate
4-byte encodings for Arm, Thumb of UDF.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D148665/new/
https://reviews.llvm.org/D148665
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
