passing rust records by value to native functions broken

[erickt]

I thought rust records were supposed to be compatible with c structs, but it seems there is an issue passing them by value to a native module. You can find a example of the bug here:

https://gist.github.com/1543358

[nikomatsakis]

The c type unsigned is not the same as the Rust type uint. Try ctypes::unsigned instead.

[erickt]

Thanks Niko. I updated my test, but I'm still running into the same issue.

On a side note, I thought commit 7fd62bb unified uint with c unsigned integer. Am I misreading the commit?

[nikomatsakis]

I believe you are misreading the commit. I think what that commit says is that "if you are targeting a 64-bit CPU, then uint and u64 are considered the same by the type checker". But unsigned in C is always u32 in Rust terms, at least on the architectures we target.

[erickt]

I found the problem. It looks like rust is passing the record by reference instead of by value. I updated my test to use fn print_foo(+f: foo) but that doesn't seem to have any effect. print_foo is still getting declared as declare i1 @print_foo({ i8*, i32 }*) in the bitcode.

[nikomatsakis]

• is "by copy". Try ++.

[erickt]

Great, that worked! The tutorial said + was by value. I'll submit a pull request to add ++ to the doc.

[erickt]

I'm reopening this because while passing by-value worked for one pointer value, it's breaking for two. I've updated my gist for a demonstration of the issue.

[graydon]

This is a whole lot more broken than it looks at first. The reason is subtle.

In any calling convention, there's a division of labour between frontend and backend. For clang+LLVM, for example, some decisions are made by the code making LLVM-API calls (which things to pass by pointer or by value) and some decisions are made by the code inside LLVM.

It turns out that the place we draw the line is not the same place clang+LLVM draw the line. Which means that when we break clang off and put rustc in its place, we're assuming LLVM is going to be doing a bunch of things magically that it will not. It was expecting clang to make some of those decisions itself. We're not emulating what clang does, so we are operating LLVM in a not-expected way. The result is we're asking LLVM to generate non-system-ABI-conformant calls.

The abi is here: http://www.x86-64.org/documentation/abi.pdf and if you scan through to section 3.2.3 on page 15, you'll see there are quite a number of very subtle rules. These combine nontrivially. In particular, in the section on aggregate handling, section 5 (c) is causing your structure (when it's larger than 2 "eightbytes") to spill to memory; clang generates code like this to receive one by return-value, and pass it on by value:

%agg.tmp = alloca %struct.foo, align 8
call void @make_foo(%struct.foo* sret %agg.tmp)
call void @take_foo(%struct.foo* byval align 8 %agg.tmp)

even though it could easily go in registers. It's not of class SSE. This is not something LLVM does for us. The logic for it is in clang, over here: http://llvm.org/svn/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp if you search for class X86_64ABIInfo

That code in turn appears to be driven by abstract parameter-attributes that are constructed over here http://llvm.org/svn/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp, if you search for ConstructAttributeList. I believe we are, more or less, going to have to emulate all this logic ourselves if we want to operate LLVM in such a way that it's ABI compatible.

This sucks and will be a whole lot of work. It's not going to be fixed in time for this release.

Thanks to echristo for helping diagnose this.