Thunks: Implement support for 32-bit Vulkan thunking #2294
Closed
Conversation
This file contains 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
This is useful information e.g. when map lookup from clang::Type pointers fails during code generation.
Repacking is fully automatic for structures composed of simple types with compatible ABI across guest/host architectures. To repack structures with pointers, the custom_repack annotation can be used. Repacking will still be automated then (with the pointer being extended from guest-size to host-size), but a call to a user-provided function is emitted to handle architecture differences.
Struct repacking logic is skipped for pointers to opaque types.
|
|
||
| // Normally, we would implement fex_custom_repack individually for each customized struct. | ||
| // In this case, they all need the same repacking, so we just implement it once and alias all fex_custom_repack instances | ||
| extern "C" const_void_ptr default_fex_custom_repack(const const_void_ptr& source) { |
There was a problem hiding this comment.
I guess these shouldn't be references since checking for nullptr on a reference is...icky?
There was a problem hiding this comment.
Oop wait, it's a reference to a pointer type, nevermind.
|
Superseded by #3487. |
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.
Simplified version of #1611, redesigned from the ground up around requirements for 32-bit Vulkan specifically. For the time being, this allows us to omit the full-blown analysis pass to check for ABI-compatibility between guest/host architectures.
Overview
This PR adds assisted automated repacking of structs with differing data layout between guest and host. Repacking is fully automatic for "simple" structures (i.e. no pointers, and all members are either built-in types with same size on guest and host or they are simple structs themselves).
For pointer members/parameters, repacking must be assisted by one of these generator annotations:
opaque_type: Used for "handle"-like types that don't have any publicly visible member data. (This will skip any repacking.)custom_repack: Allows for a user-provided function to be called after size-extending the pointer to host-layout. All other architecture differences are assumed to be taken care of by that function.param_is_sized_array: Used to specify that a function parameter is a dynamically-sized array, the size of which is specified by another function parameter. Repacking logic (if needed) is recursively applied to each element in the array. (NOT IMPLEMENTED)Impact
All currently thunked libraries will likely need annotations for pointer-types throughout their respective APIs. The full scope of this is TBD.
TODO
(incomplete)
param_is_sized_arrayannotation