this is to prevent a situation when a pointer is invalid or null,
but we get to reading from vtable before we can check that
(possibly causing a segfault without a good diagnostics).
Details
Diff Detail
- Build Status
Buildable 1187 Build 1187: arc lint + arc unit
Event Timeline
Test case?
lib/CodeGen/CGExprCXX.cpp | ||
---|---|---|
93 | Is it correct to emit a type check at this point? Looking at [0] it looks like this function is only called from the Microsoft C++ ABI after we have already resolved the virtual function pointer. [0] http://llvm-cs.pcc.me.uk/tools/clang/lib/CodeGen/CGExprCXX.cpp/rEmitCXXDestructorCall |
All UBSan test cases happen to live in compiler-rt. I have added a couple of test cases in https://reviews.llvm.org/D26560.
Also, I am not against adding Clang counterparts for them which would test IL instead of the output from running. But it probably deserves a separate CL, as it has nothing to do with fixing this particular bug.
Small correction: all UBSan type checks tests live in compiler-rt. There is a test for UBsan + devirtualization inside tools/clang. My point still stands.
We normally update the IR tests whenever we change IRgen. If we're missing test coverage, we should add it before landing this.
lib/CodeGen/CGExprCXX.cpp | ||
---|---|---|
93 | What about this comment? |
lib/CodeGen/CGExprCXX.cpp | ||
---|---|---|
93 | Sorry, I have missed the comment. I have added this check here to preserve the existing behavior. From what you describe, there could be a very similar issue related to the Microsoft C++ ABI to the one that I fix here. I am okay to file a bug or add a note about this, your choice. |
lib/CodeGen/CGExprCXX.cpp | ||
---|---|---|
93 | Have you looked at how hard it would be to fix this? |
lib/CodeGen/CGExprCXX.cpp | ||
---|---|---|
93 | Done. Note: since I don't have an ability to test on Windows, this CL is now high-risk. If it breaks any Windows-specific tests, when submitted, I will revert the CL and undo the MSABI change. After all, the previous state was to keep things working as they were before. |
lib/CodeGen/CGExprCXX.cpp | ||
---|---|---|
1928–1933 | This could all be moved into EmitObjectDelete. | |
lib/CodeGen/MicrosoftCXXABI.cpp | ||
1820–1833 ↗ | (On Diff #77941) | If you undo this part do the tests still pass? |
lib/CodeGen/MicrosoftCXXABI.cpp | ||
---|---|---|
1820–1833 ↗ | (On Diff #77941) | Thank you for the catch. Yes, the other check covers this case too. Reverted this file. |
test/CodeGenCXX/ubsan-vtable-checks.cpp | ||
---|---|---|
23 ↗ | (On Diff #78240) | Fixed. |
LGTM
lib/CodeGen/CGExprCXX.cpp | ||
---|---|---|
1768 | You could cite C++11 [expr.delete]p3 here: "if the static type of the object to be deleted is different from its |
Is it correct to emit a type check at this point? Looking at [0] it looks like this function is only called from the Microsoft C++ ABI after we have already resolved the virtual function pointer.
[0] http://llvm-cs.pcc.me.uk/tools/clang/lib/CodeGen/CGExprCXX.cpp/rEmitCXXDestructorCall