-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix incorrect constant for O_LARGEFILE on mips64-linux-musl #2875
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Amanieu (or someone else) soon. Please see the contribution instructions for more information. |
Thanks for the detailed explanation, I also confirmed the value on the musl source: https://github.com/bminor/musl/blob/cfdfd5ea3ce14c6abf7fb22a531f3d99518b5a1b/arch/mips64/bits/fcntl.h#L16 cc @Grommish the value is going to be changed as the value is incorrect. @bors r+ |
Fix incorrect constant for O_LARGEFILE on mips64-linux-musl Changes `O_LARGEFILE` from `0` to `0x2000` Bash script used for ensuring constant is correct: ```sh #!/bin/bash echo " #include <fcntl.h> int largefile() { return O_LARGEFILE; } " | mips64-linux-musl-gcc -c -O2 musl_o_largefile.c -o temp.o mips64-linux-musl-objdump -d temp.o | grep -A2 largefile ``` Output: ```asm 0000000000000000 <largefile>: 0: 03e00008 jr ra 4: 24022000 li v0,8192 ; 0x2000 ``` Link to relevant portion of kernel source, shows that it should match mips32 musl (which currently has a value of 0x2000 as well). I believe the reason #2738 had this value incorrect was because it's 0 for glibc on mips64 (to specify it's the default, I believe).
💥 Test timed out |
@bors retry |
☀️ Test successful - checks-actions, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13, checks-cirrus-freebsd-14 |
Changes
O_LARGEFILE
from0
to0x2000
Bash script used for ensuring constant is correct:
Output:
Link to relevant portion of kernel source, shows that it should match mips32 musl (which currently has a value of 0x2000 as well).
I believe the reason #2738 had this value incorrect was because it's 0 for glibc on mips64 (to specify it's the default, I believe).