-
Notifications
You must be signed in to change notification settings - Fork 15.1k
[clang][PAC] Fix builtins that claim address discriminated types are bitwise compatible #154490
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 2 commits
689d70c
5c4a30b
18f035b
587864c
fb069dd
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -74,7 +74,7 @@ static_assert(__is_trivially_destructible(S3)); | |
| static_assert(!__is_trivially_copyable(S3)); | ||
| static_assert(!__is_trivially_relocatable(S3)); // expected-warning{{deprecated}} | ||
| //FIXME | ||
| static_assert(__builtin_is_cpp_trivially_relocatable(S3)); | ||
| static_assert(!__builtin_is_cpp_trivially_relocatable(S3)); | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm, is this right? My understanding is that, while the pre-standardization concept of trivial relocatability implies bitwise relocation, the standardized concept does not and allows for arbitrary compiler-synthesized logic as long as that logic can't cause arbitrary side-effects. I would expect address-discriminated ptrauth to not disqualify a type from that. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @rjmccall (I have no idea if pinging like this impacts GH behavior so this is more a test than anything else) So the issue here is that we weren't sure how to handle explicitly ptrauth qualified values, and then with everything else didn't end up landing the trivially_relocate support at all, and that PR is large enough that I would be worried about landing it in llvm21 at this point. @cor3ntin and I discussed this and thought that having this return false until we actually supported trivial relocation was the best approach even though it could in principle impact abi when we do enable it. The trivially_relocate PR is over at #144420 and you can see it is quite a big one. On the other hand it really only impact types containing address discriminated values so if there were any issues the impact would be extremely restricted, and assuming that the use of explicit pointer auth in code built with llvm21, the most common place it would be encountered is when trivially relocating polymorphic types which is something that I really don't like at all, and wish was not permitted as IMO it's a bigger hazard than copy behavior due to it maintaining the vtable pointer for a potentially truncated object. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see. The idea is that it should work, and while we don't support it today, we do intend to in the future? That seems reasonable. Wait, trivial relocation of a polymorphic object just copies the v-table pointers? That seems obviously incorrect unless there's some semantic reason relocation can only happen on complete objects. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I also dislike it - but a bunch of people believe that it absolutely must be a memcpy. Allowing a fixup for ptrauth was a struggle as it was. A non-zero part of me wants it to be an error if there's a constant copy size of one element - on the basis that a variable count implies that you have an array so they must all be the same type. But yeah, blind copy of the vtable is questionable, but once again just slap a "it's UB to truncate the object" is the solution :-/ There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's possible we could argue against it in Kona - I think @ldionne already has a few problems with it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Alright, I'm fine with the plan here. |
||
| static_assert(!__is_trivially_equality_comparable(S3)); | ||
|
|
||
|
|
||
|
|
@@ -84,7 +84,7 @@ static_assert(!__is_trivially_assignable(Holder<S3>, const Holder<S3>&)); | |
| static_assert(__is_trivially_destructible(Holder<S3>)); | ||
| static_assert(!__is_trivially_copyable(Holder<S3>)); | ||
| static_assert(!__is_trivially_relocatable(Holder<S3>)); // expected-warning{{deprecated}} | ||
| static_assert(__builtin_is_cpp_trivially_relocatable(Holder<S3>)); | ||
| static_assert(!__builtin_is_cpp_trivially_relocatable(Holder<S3>)); | ||
| static_assert(!__is_trivially_equality_comparable(Holder<S3>)); | ||
|
|
||
| struct IA S4 { | ||
|
|
@@ -207,7 +207,7 @@ template <class T> struct UnionWrapper trivially_relocatable_if_eligible { | |
| } u; | ||
| }; | ||
|
|
||
| static_assert(test_is_trivially_relocatable_v<AddressDiscriminatedPolymorphicBase>); | ||
| static_assert(!test_is_trivially_relocatable_v<AddressDiscriminatedPolymorphicBase>); | ||
| static_assert(test_is_trivially_relocatable_v<NoAddressDiscriminatedPolymorphicBase>); | ||
| static_assert(inheritance_relocatability_matches_bases_v<AddressDiscriminatedPolymorphicBase, NoAddressDiscriminatedPolymorphicBase>); | ||
| static_assert(inheritance_relocatability_matches_bases_v<NoAddressDiscriminatedPolymorphicBase, AddressDiscriminatedPolymorphicBase>); | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this function and
containsAddressDiscriminatedPointerAuthnow do the same thing, can we remove one of them?