This is an archive of the discontinued LLVM Phabricator instance.

Use FrameIndexTy for stack protector
ClosedPublic

Authored by arichardson on Apr 9 2020, 2:30 AM.

Details

Summary

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().

Diff Detail

Event Timeline

arichardson created this revision.Apr 9 2020, 2:30 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 9 2020, 2:30 AM
arichardson edited the summary of this revision. (Show Details)Apr 9 2020, 2:35 AM
arsenm accepted this revision.Apr 9 2020, 9:28 AM

This is really a workaround. The stacksave intrinsic should have the same address space as the alloca address space

This revision is now accepted and ready to land.Apr 9 2020, 9:28 AM

This is really a workaround. The stacksave intrinsic should have the same address space as the alloca address space

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.

This revision was automatically updated to reflect the committed changes.