You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a stronger form of #141. In order to have more perfect unstripping, we need to remove all special treatment for corlib primitives. They will no longer be used in place of their Il2Cpp variants.
Implementation Details
The Il2Cpp primitives will need bidirectional implicit conversion operators to their System counterparts.
During unstripping, instance methods can be called on these primitives. Currently, this is limited to static methods.
IL Complications
Any IL instruction directly related to numeric operations on the stack, eg ldc.i4, may require special handling. This could become quite complicated.
Alternatives
Do Nothing
We could allow this to fail at runtime with missing method exceptions. That is not ideal, but it is a valid approach until #141 is implemented, which will break references that involve string. Similarly, this approach is not compatible with #173.
Note: there may be subtle differences between the Unity implementation and the CoreCLR implementation. For example, I think floating point serialization is slightly different.
Fail When Primitive Instance Methods Are Referenced
This isn't ideal, but it's completely compatible with #141 and #173.
Fail When The Signature Would Be Different
Same as the previous option, except the code is smarter.
Call The Instance Methods Anyway
As long as the runtime doesn't complain, it should be safe to call the instance methods on the numeric primitives, since they have the same memory layout. For example, ILSpy shows this as:
((Int32*)(&index))->ToString()
Generate Extension Methods
We could generate extension methods that wrap the Il2Cpp instance methods. It would look roughly like this:
Context
This is a stronger form of #141. In order to have more perfect unstripping, we need to remove all special treatment for corlib primitives. They will no longer be used in place of their Il2Cpp variants.
Implementation Details
IL Complications
Any IL instruction directly related to numeric operations on the stack, eg
ldc.i4
, may require special handling. This could become quite complicated.Alternatives
Do Nothing
We could allow this to fail at runtime with missing method exceptions. That is not ideal, but it is a valid approach until #141 is implemented, which will break references that involve
string
. Similarly, this approach is not compatible with #173.Note: there may be subtle differences between the Unity implementation and the CoreCLR implementation. For example, I think floating point serialization is slightly different.
Fail When Primitive Instance Methods Are Referenced
This isn't ideal, but it's completely compatible with #141 and #173.
Fail When The Signature Would Be Different
Same as the previous option, except the code is smarter.
Call The Instance Methods Anyway
As long as the runtime doesn't complain, it should be safe to call the instance methods on the numeric primitives, since they have the same memory layout. For example, ILSpy shows this as:
Generate Extension Methods
We could generate extension methods that wrap the Il2Cpp instance methods. It would look roughly like this:
https://sharplab.io/#v2:C4LglgNgPgxAdgVwhAhgIwgUwAQBMwDO6WAsAFAACAzNhQIwBstATNgMLYDe52v2A9P2wA5APbAcwABYpg2aTgCSAGWwBzTHEwAnWZlzY0AT2wAlUQQhG42QvKk4iAWxwAzUdvuYCkgO6jsF2lRXAIAOh4+QWwAFQcfQMxg0Ox/JAMUAGNgBBRkEzQcCgAGbEUIZjYAByr6MIBlYG0wODUAGkjeaLQEOUVsUScwYAkDaVlsd080bUwAN2GTFDgDFWxMrGWIFu9wztoaeiZ6UoBZOgAKAEoufb5aAHY8TFcUJGALluArsJjRRuarWuAG59gBffbUWiMaFnZjXW5ke73ChPcqVGoACUwECqOnCijgwCozAAogAPCRwAhgUTU37/JotNQXXAvN4QD5fK5XUFIvgQsiCuAoFwEKpZJQVaq1Ojkbj83hQ2YoXB0qzYAhNBDZMpEkmfInYOZ5BCYK77BXIvhVZomiTYFVquAar7G004AC87ogZr5dz4UNEcx0zTZsNijMBLItiuRVutyOicTsdgAVggtdgUJqcmhbE4qlgXETZLSbFMvNhMOTRUXMAByAialAAa0wETjiYEQjiOCyOTyBfrJeAZbpqVE6XWeQgtiJAXRMuwIuAYBD6xCHYD1tRPrNDIBzJBO+wgu7p6hR2H20ywwGeN0wA884+hOJrBNvvN2E9AD59w7L8/VPS9DhhMBC1ve9REfWQX3fA03WAn9/xXTBfAuFDeXBchhVFbwJUyKUMSqbFcXxeVIXA45WEQslKU0Gk6WbBNrWiAB1HBMxwAAiFpeMMTBMjeBJZyrW1IOGddvGzWZHUwVV1SMTtuyvGETkjI8gWkVMbDdCgKF0ggbjY7tHmwC4LiXGo6noq5DOMn4/m0mM+W7c8BTwoA===
Related
#171
The text was updated successfully, but these errors were encountered: