support x86_64 return calling conventions #610
Merged
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
|
Thanks for the PR! ✨ This is a little outside of my area of expertise, but: any idea how we can test this? I assume there's cases where if the size is incorrect, we could crash? Probably tricky, but I definitely think it would be great to have a reproducible crash that this patch fixes! |
|
Yeah, this is pretty hard to test. It depends on the architecture being built as well as the whim of the compiler. In my case it was rare for the x86_64 compiler to use more than 8 bytes but when it did, it would cause a crash. Based on http://wiki.osdev.org/Calling_Conventions I'm concluding that this can be allowed to be up to 16 bytes on x86_64; sizeof(rax + rdx) |
|
This is probably good to merge 👍 |
# for free
to join this conversation on GitHub.
Already have an account?
# 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.
Covers issues that arise when structs are larger than 8 bytes are returned on the call stack on x86_64 targets. I'm not sure if there may be other places this comes up, but I think this is a start.