Using getValueType() is not correct for architectures extended with CHERI since
we need a pointer type and not the value that is loaded. While stack
protector is useless when you have CHERI (since CHERI provides much
stronger security guarantees), we still have a test to check that we can
generate correct code for checks. Merging b281138a1b67ca4405b77d774adc3de72742e7a2
into our tree broke this test. Fix by using TLI.getFrameIndexTy().
Details
Details
- Reviewers
arsenm - Commits
- rGbbcfce4badac: Use FrameIndexTy for stack protector
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Unit Tests
Event Timeline
Comment Actions
This is really a workaround. The stacksave intrinsic should have the same address space as the alloca address space
Comment Actions
I'm not sure the canary value needs to be the same type as an alloca address space pointer, I could also imagine people wanting to store a code pointer or an arbitrary integer instead?
In any case, the pointer to load the value is definitely a FrameIndexTy so I think this is the correct regardless of whether the stackguard/stackprotector intrinsics are changed to use llvm_anyptrptr_ty.