Fix native main() signature on 64bit #44906
Conversation
Add c_int for use in the compiler, assuming i32 for all targets as in libc.
To match the C signature, main() should be generated with C int type for the argc parameter and result, i.e. i32 instead of i64 on 64bit. That way it no longer relies on the upper 32 bits being zero, which I'm not sure is guaranteed by ABIs or startup code.
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
At first glance -- can we add some sort of test here? |
|
I'm new to rustc and its test suite, but I got a codegen test like the following working: Is that ok/the right way to do it? |
|
Yes, that is fine. |
src/librustc_trans/type_.rs
Outdated
| @@ -140,6 +140,10 @@ impl Type { | |||
| } | |||
| } | |||
|
|
|||
| pub fn c_int(ccx: &CrateContext) -> Type { | |||
| Type::i32(ccx) | |||
There was a problem hiding this comment.
This doesn’t seem like a particularly good implementation of c_int. That being said, liblibc defines type c_int = i32 for everything, so it is fine, I guess?
There was a problem hiding this comment.
Yea, my thoughts exactly. It should be derived from the target context, as done for Type::isize() with target_pointer_width. But I thought that's not needed yet, because libc currently always uses i32 anyways. (does rustc support target platforms with 16bit/64bit C int?)
There was a problem hiding this comment.
AVR uses a 16-bit int. I'll leave a comment on the tracking issue so this gets fixed if/when that gets upstreamed.
There was a problem hiding this comment.
And MSP430 also. We currently support that target, but I don't think that needs to block this PR since this is strictly better than what we're already doing. (using i64).
There was a problem hiding this comment.
isize is 16 bit on MSP:
So this PR would bump the argument from i16 to i32. The registers in MSP are 16-bits, and arguments are passed in registers, so this will most likely break the calling convention.
There was a problem hiding this comment.
Ah, I missed that. Going to work on a fix.
|
r=me with the codegen test as seen few comments above. |
shepmaster
added
the
S-waiting-on-author
|
@bors r+ |
|
📌 Commit 6c3f190 has been approved by |
nagisa
added
S-waiting-on-bors
|
@bors r- Until MSP/AVR/c_int situation is figured out. It might regress some targets. |
nagisa
added
S-waiting-on-author
(all i32 for now, as in liblibc)
Fix regression from c2fe69b, where main() signature was changed from using 16bit isize to 32bit c_int for argc parameter/result.
|
I've extended the target specifications with a field for c_int width, and set it to i16 for MSP. The same can probably be done for AVR. |
|
Some tests have failed: You’ll need to adjust test to specify |
|
@bors r+ |
|
📌 Commit a4e8373 has been approved by |
|
⌛ Testing commit a4e8373 with merge cfd927906b2fe00103f898ffc466d8b5c84e3cb2... |
|
💔 Test failed - status-appveyor |
|
@bors retry Failure seems potentially spurious to me? cc @alexcrichton @Mark-Simulacrum |
Fix native main() signature on 64bit Hello, in LLVM-IR produced by rustc on x86_64-linux-gnu, the native main() function had incorrect types for the function result and argc parameter: i64, while it should be i32 (really c_int). See also #20064, #29633. So I've attempted a fix here. I tested it by checking the LLVM IR produced with --target x86_64-unknown-linux-gnu and i686-unknown-linux-gnu. Also I tried running the tests (`./x.py test`), however I'm getting two failures with and without the patch, which I'm guessing is unrelated.
|
☀️ Test successful - status-appveyor, status-travis |
|
Spurious failure issue: #43402 |
Hello,
in LLVM-IR produced by rustc on x86_64-linux-gnu, the native main() function had incorrect types for the function result and argc parameter: i64, while it should be i32 (really c_int). See also #20064, #29633.
So I've attempted a fix here. I tested it by checking the LLVM IR produced with --target x86_64-unknown-linux-gnu and i686-unknown-linux-gnu. Also I tried running the tests (
./x.py test), however I'm getting two failures with and without the patch, which I'm guessing is unrelated.