[AArch64][PAC] Emit a fatal error when ptrauth target feature is missing#62
[AArch64][PAC] Emit a fatal error when ptrauth target feature is missing#62
Conversation
Previously, in `expandPtrAuthPseudo` we expanded `MOVaddrPAC`, `LOADgotPAC` and `LOADauthptrgot` pseudo-instructions without taking presense of PAuth subtarget feature into account. In case of `LOADauthptrgot`, it resulted in undesired so-called `$auth_ptr$` stub and a corresponding AUTH relocation. In case `MOVaddrPAC` and `LOADgotPAC`, it resulted in pac-specific instructions (e.g. `paciza`) emitted which was only caught via assertion during machine instructions verification (and not caught at all when assertions are disabled). This patch makes us emit a fatal error and fail fast in such cases.
|
@atrosinenko please review |
The option is not present on assertion-disabled builds. A test without the option (and without verifying debug output ensuring which particular pseudo-instructions are expanded) is also added - it looks reasonable since the PR itself is intended to add proper error handling for assertion-disabled builds.
atrosinenko
left a comment
atrosinenko
left a comment
There was a problem hiding this comment.
I wonder if other code paths have to be guarded as well.
|
|
||
| ;--- MOVaddrPAC.ll | ||
|
|
||
| ; RUN: not --crash llc -debug -mtriple aarch64-elf MOVaddrPAC.ll 2>&1 | \ |
There was a problem hiding this comment.
-debug may be replaced with -debug-only=aarch64-expand-hardened-pseudos for less verbose debug output (not sure which is more canonical in tests, though).
|
@atrosinenko Thanks for review. Several points: |
atrosinenko
left a comment
atrosinenko
left a comment
There was a problem hiding this comment.
Is AArch64ExpandHardenedPseudos::expandAuthLoad method expected to contain a similar check?
| define i8* @foo() #0 { | ||
| %tmp = bitcast { i8*, i32, i64, i64 }* @g_weak.ptrauth to i8* | ||
| ret i8* %tmp | ||
| } | ||
|
|
||
| @g_weak = extern_weak global i32 | ||
| @g_weak.ptrauth = private constant { i8*, i32, i64, i64 } { i8* bitcast (i32* @g_weak to i8*), i32 0, i64 0, i64 0 }, section "llvm.ptrauth" |
| define i8* @foo() #0 { | ||
| %tmp = bitcast { i8*, i32, i64, i64 }* @g_weak.ptrauth to i8* | ||
| ret i8* %tmp | ||
| } | ||
|
|
||
| @g_weak = extern_weak global i32 | ||
| @g_weak.ptrauth = private constant { i8*, i32, i64, i64 } { i8* bitcast (i32* @g_weak to i8*), i32 0, i64 0, i64 0 }, section "llvm.ptrauth" |
@atrosinenko In bffc609 I've added checks in |
atrosinenko
left a comment
atrosinenko
left a comment
There was a problem hiding this comment.
Sorry for too many iterations, I just spotted the tests are in the llvm/lib/Target/AArch64/GISel/ directory. Maybe these could be moved to llvm/lib/Target/AArch64 and updated to test both DAGISel and GlobalISel like it is done in ptrauth-intrinsic-blend.ll. This should make TODO unneeded, I guess.
|
@atrosinenko Thanks, testing both with I don't feel the approach initially taken suites best now - trying to guard every place where we potentially emit auth-specific instructions makes things harder to maintain, understand, and there are way too many points responsible for checking such a simple things. I suppose the following approach could be better.
Please let me know your thoughts on this. Thanks! |
3 participants
Previously, in
expandPtrAuthPseudowe expandedMOVaddrPAC,LOADgotPACandLOADauthptrgotpseudo-instructions without taking presense of PAuth subtarget feature into account. In case ofLOADauthptrgot, it resulted in undesired so-called$auth_ptr$stub and a corresponding AUTH relocation. In caseMOVaddrPACandLOADgotPAC, it resulted in pac-specific instructions (e.g.paciza) emitted which was only caught via assertion during machine instructions verification (and not caught at all when assertions are disabled).This patch makes us emit a fatal error and fail fast in such cases.