Clang: Fix elementtype attribute mismatch in thunk generation #336
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
yuri91
requested changes
Dec 8, 2025
Member
yuri91
left a comment
yuri91
left a comment
There was a problem hiding this comment.
You found the right spot. But the fix needs some more work
clang/lib/CodeGen/CGVTables.cpp
Outdated
| // between the function signature and the elementtype attribute | ||
| llvm::Type* CurrentThisTy = nullptr; | ||
| if (auto* PtrTy = dyn_cast<llvm::PointerType>(ActualParamType)) { | ||
| CurrentThisTy = PtrTy->getPointerElementType(); |
Member
There was a problem hiding this comment.
getPointerElementType() is a deprecated function. We should not use it, and actually the main reason for the elementtype attribute is to avoid having to resort to getPointerElementType().
See if there is any other way to get the element type fom Clang here.
Author
There was a problem hiding this comment.
Yes, I see I had issues with opaque pointers and added a check to prevent opaque pointers to try and call this function in my new chnages but just read your comment now so the version I pushed still has the getPointerElementType() in there. I'll try to find a way not to use it
andmadri
force-pushed
the
clang_fix_elemettype
branch
from
ff91653 to
4240a25
Compare
When processing thunk functions and elementtypes with inheritance, there were logic errors in the direct base checking that could lead to incorrect function types being retained. The issue occurred in the following case: 1. Initial comparison: CurrentThisStructTy (ios_base) == NewThisTy (ios_base) - Both types are the same, so NewIsDirectBase is incorrectly set to true - ThunkFn type: void (%class._ZSt8ios_base*) - ThunkFnTy: (%class._ZSt8ios_base*) - Since types match, no update occurs 2. Second comparison: CurrentThisStructTy != NewThisTy - ThunkFn then gets updated to void (%class._ZSt9basic_iosIcSt11char_traitsIcEE*) - This is correct behavior 3. Third comparison: Same types again (ios_base == ios_base) - NewIsDirectBase is again set to true, which will then affect updating the ThunkFn - Current ThunkFn: void (%class._ZSt9basic_iosIcSt11char_traitsIcEE*) but the one we want to update to is void (%class._ZSt8ios_base*) - Because NewIsDirectBase is true, the update is skipped eventhough ThunkFn != ThunkFnTy. This leaves ThunkFn with the wrong type
andmadri
force-pushed
the
clang_fix_elemettype
branch
from
69b9718 to
55fb6ba
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When processing thunk functions and elementtypes with
inheritance, there were logic errors in the direct base checking
that could lead to incorrect function types being retained.
The issue occurred in the following case:
but the one we want to update to is void (%class._ZSt8ios_base*)
ThunkFn != ThunkFnTy. This leaves ThunkFn with the wrong type