-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
CFI: Support function pointers for trait methods #123052
Changes from all commits
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 |
---|---|---|
|
@@ -18,5 +18,5 @@ impl Trait1 for Type1 { | |
} | ||
|
||
|
||
// CHECK: ![[TYPE1]] = !{i64 0, !"_ZTSFvu3refIu3dynIu{{[0-9]+}}NtC{{[[:print:]]+}}_{{[[:print:]]+}}6Trait1u6regionEEE"} | ||
// CHECK: ![[TYPE2]] = !{i64 0, !"_ZTSFvu3refIu{{[0-9]+}}NtC{{[[:print:]]+}}_{{[[:print:]]+}}5Type1EE"} | ||
// CHECK: ![[TYPE1]] = !{i64 0, !"_ZTSFvu3refIu{{[0-9]+}}NtC{{[[:print:]]+}}_{{[[:print:]]+}}5Type1EE"} | ||
// CHECK: ![[TYPE2]] = !{i64 0, !"_ZTSFvu3refIu3dynIu{{[0-9]+}}NtC{{[[:print:]]+}}_{{[[:print:]]+}}6Trait1u6regionEEE"} | ||
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. As a result of what I mentioned above, it seems the type id order also changed here. 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. Yes. I'm not sure why the type order changing is an issue if we only have one test that checks 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. The tests aren't an issue now. My disagreement is with the less common case (i.e., not performing self type erasure/the secondary type id) being the default behavior and also the first type id. |
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.
I don't know, I kinda disagree with the change to the NO_SELF_TYPE_ERASURE. I think the default should be what is going to be done most of the time or more commonly, and it's performing type erasure. The exception for the secondary type id should be opted in when needed.
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.
I don't have a strong preference - I like this version a little better due to the "positive" nature of it.
With regards to defaults vs secondary, only KCFI has a meaningful notion of a "default" type ID - CFI attaches all of them to the same attachment site, so none of them are really primary or secondary. KCFI still sets
ERASE_SELF_TYPE
as its default with this changeset.That said, if this change is contentious and not required by compiler-errors to land this PR, I don't really care to fight over this.
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.
It's secondary because these are not always included. They're only included when they're unique and for methods, and also are only tested for when methods are used as function pointers so the concept of secondary does apply generally.