-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Call to Rust extern "fastcall" function does not follow GNU/Clang fastcall convention #18086
Comments
This llvm-dev thread looks relevant: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-October/054629.html |
This is currently blocking a lot of things I'd like to do in Rust, and is requiring an awful C wrapper library just for calling conventions. |
Traige: trying to reproduce, adding
This seems better than a segfault, but still not good? |
Same here. It seems, "fastcall" is not correct still: testcase. extern "fastcall" fn inner_call(a: u32, b: u8, c: u16) -> u32 {
a + b as u32 + c as u32
}
#[link(name="outer")]
extern "fastcall"
{
fn outer_call(a: u32, b: u8, c: u16) -> u32;
}
fn main() {
let r1 = inner_call(1,2,3);
let r2 = unsafe { outer_call(1,2,3) };
println!("fcall: {} and {}", r1, r2);
} unsigned __fastcall outer_call(unsigned int a, unsigned char b, unsigned short c) {
return a + b + c;
} Meta
|
From @pravic's examples, declare x86_fastcallcc i32 @"\01@outer_call@12"(i32 inreg, i8 inreg zeroext, i16 zeroext) While declare x86_fastcallcc i32 @outer_call(i32, i8 zeroext, i16 zeroext) Naming aside (it ends up linking just fine), we're missing |
@whitequark @edef1c we could use this for libfringe. |
Fix fastcall not applying inreg attributes to arguments Fixes #18086
…r=Veykril Use more correct handling of lint attributes The previous analysis was top-down, and worked on a single file (expanding macros). The new analysis is bottom-up, starting from the diagnostics and climbing up the syntax and module tree. While this is more efficient (and in fact, efficiency was the motivating reason to work on this), unfortunately the code was already fast enough. But luckily, it also fixes a correctness problem: outline parent modules' attributes were not respected for the previous analysis. Case lints specifically did their own analysis to accommodate that, but it was limited to only them. The new analysis works on all kinds of lints, present and future. It was basically impossible to fix the old analysis without rewriting it because navigating the module hierarchy must come bottom-up, and if we already have a bottom-up analysis (including syntax analysis because modules can be nested in other syntax elements, including macros), it makes sense to use only this kind of analysis. Few other bugs (not fundamental to the previous analysis) are also fixed, e.g. overwriting of lint levels (i.e. `#[allow(lint)] mod foo { #[warn(lint)] mod bar; }`. After this PR is merged I intend to work on an editor command that does workspace-wide diagnostics analysis (that is, `rust-analyzer diagnostics` but from your editor and without having to spawn a new process, which will have to analyze the workspace from scratch). This can be useful to users who do not want to enable check on save because of its overhead, but want to see workspace wide diagnostics from r-a (or to maintainers of rust-analyzer). Closes rust-lang#18086. Closes rust-lang#18081. Fixes rust-lang#18056.
For a call to an extern "fastcall" function on 32-bit Linux, rustc passes arguments via the stack instead of via registers, and it doesn't pop the arguments from the stack after the call. I was expecting rustc to follow the GNU/Clang "fastcall" convention (http://en.wikipedia.org/wiki/X86_calling_conventions#fastcall). Instead, it seems to be following something like the "stdcall" convention.
Test case:
Output:
Here's the assembly output from main (with some stuff elided):
I compiled both
fastcall_good_caller.c
andfastcall_caller.rs
to LLVM IR, and the difference seems to be aninreg
keyword. Clang outputs it, but Rust doesn't.fastcall_good_caller.ll:
fastcall_caller.ll:
The text was updated successfully, but these errors were encountered: