Skip to content

make native and crust functions conform to x86-64 ABI - #1970

Closed
crabtw wants to merge 1 commit into
rust-lang:masterfrom
crabtw:x86-64-abi
Closed

make native and crust functions conform to x86-64 ABI#1970
crabtw wants to merge 1 commit into
rust-lang:masterfrom
crabtw:x86-64-abi

Conversation

@crabtw

Copy link
Copy Markdown
Contributor
  • add functions to classify argument and return types
  • convert argument and return types of native function in shim function
  • convert argument and return types of crust function in wrap function

@brson

Copy link
Copy Markdown
Contributor

Thank you! This looks really interesting, but I haven't looked at it closely yet.

I would like some tests, though I realize there's not a way to test this in our current test suite. One thing you could do, that I have done before and would be fine with here, is add some functions to the runtime, possibly under src/rt/rust_test_x86_64.cpp that exhibit some of the problems this is addressing, and prefix them rust_dbg_. Then exercise those functions in some tests.

@brson

Copy link
Copy Markdown
Contributor

Does this completely fix #1402?

@crabtw

Copy link
Copy Markdown
ContributorAuthor

Yes, it fixes #1402 .
I will add some tests and move ABI dependent code to another module to make it more extensible.

@graydon

Copy link
Copy Markdown
Contributor

This is fantastic! Thank you so much.

My only concerns are, as you say, modularizing it a bit (per-arch) and making some tests. But I'm happy to do that work myself while integrating it. You did the hard part. Let me know if you prefer to do that yourself or have me do it. It's fine either way.

@crabtw

Copy link
Copy Markdown
ContributorAuthor

I think you can do it better than me, so please do it.
Thank you!

@ghostghost assigned graydonMar 20, 2012
@graydon

Copy link
Copy Markdown
Contributor

Actually I'm going to land this first and then modularize and test in subsequent steps. Assuming it bootstraps; we do need this sort of code in one form or another.

@graydon

Copy link
Copy Markdown
Contributor

This is now integrated, thanks! I'm going to leave the issue just a little while longer to remind me to write tests. Modularizing can come later; I just want to make sure it fixes #1402.

@graydongraydon reopened this Mar 21, 2012
@graydon

Copy link
Copy Markdown
Contributor

Fails testcase I threw together. I'll start debugging. Reopening.

@graydon

Copy link
Copy Markdown
Contributor

Oh, seems to fail on x86 not x86_64. I think probably that path was broken before, then. I'll file a separate bug on just that case and re-close this. Thanks.

@graydongraydon closed this Mar 21, 2012
U007D pushed a commit to U007D/rust-mos that referenced this pull request Aug 21, 2026
1970: Add <> when completing generics r=matklad a=matklad
@flodiebold wdyt? Is it correct that we always need to add `<>` in generic types? Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
U007D pushed a commit to U007D/rust-mos that referenced this pull request Aug 21, 2026
…fJung
Allow varargs for libc::open when it is allowed by the second argument
This PR allows `libc::open` to be called using two or three arguments as defined in https://man7.org/linux/man-pages/man2/open.2.html
The presence of the third argument depends on the value of the second argument. If the second argument dictates that the third argument is *required* miri will emit an error if the argument is missing. If the second argument does *not* require a third argument, then the argument is ignored and passed as 0 internally (it would be ignored by libc anyway)
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@crabtw@brson@graydon