OSDev.org

I've decided to give Rust language a shot. And frankly, I like it. But there are some things about it, I would like to know in more detail.

How is Rust ABI on x86, AMD64, ARM32 and ARM64 defined? Is Rust ABI stable? How registers are used? What is stack frame layout? How does name mangling work in Rust?

For now I am using extern "C" blocks to interface with assembler code, but it would be nice to, at least, know how its native calls work.

pvc wrote:Is Rust ABI stable?

It does not. You have to use the c abi.

The Rust ABI is not stable and most likely never will be, and I suspect that this is intentional. And if it is, its very understandable. Rust brings to the table a lot of things that would be difficult to actually formalize in an ABI. As such, the Rust ABI doesn't guarantee much if anything at all. Even if you turn off name mangling, calling a pure rust function from another language just wouldn't work since anything could change at any time.
Using extern "C" around any external functions (along with #[no_mangle]) is exactly how you export and import functions from other languages. (#[no_mangle] is only used in function exportation.) You will, of course, need to then conform to the C ABI, but that's not too difficult.

You may be interested in this page: https://doc.rust-lang.org/nomicon/ffi.html

pvc wrote:How is Rust ABI on x86, AMD64, ARM32 and ARM64 defined? Is Rust ABI stable? How registers are used? What is stack frame layout? How does name mangling work in Rust?

This is hilarious. Here's a link to the ABI, but that page actually doesn't talk about anything binary interface related! It's like those Rust guys wouldn't know the difference between API and ABI at all... WTF?

More info: rust-abi-wiki (not reassuring that they are only planning to make a stable ABI, but not achieved so far)

Fun fact: Google has banned Rust from the Zirchon kernel. Reason: "The properties of the language are not yet well-understood, having selected an unusual language design point". Nice way to say it's a mess lacking well-designed structures...

The deeper I dig into Rust and the more disgusted I became, personal opinion only.

Cheers,
bzt

If you follow the links, rather than concentrating on a single page, you'll see that Rust allows you to specify that the C ABI is used. As that is pretty well documented, there's no need to duplicate that effort.

Rust as pure Rust doesn't use a standard ABI. If you're not linking with external functions or machine code, what does it matter what calling conventions are used under the hood?

So you have the choice - use the most efficient calling conventions specified for your particular Rust compiler, or use the - probably - less efficient C ABI.

Choice is good.

bzt wrote:

pvc wrote:How is Rust ABI on x86, AMD64, ARM32 and ARM64 defined? Is Rust ABI stable? How registers are used? What is stack frame layout? How does name mangling work in Rust?

This is hilarious. Here's a link to the ABI, but that page actually doesn't talk about anything binary interface related! It's like those Rust guys wouldn't know the difference between API and ABI at all... WTF?

More info: rust-abi-wiki (not reassuring that they are only planning to make a stable ABI, but not achieved so far)

Fun fact: Google has banned Rust from the Zirchon kernel. Reason: "The properties of the language are not yet well-understood, having selected an unusual language design point". Nice way to say it's a mess lacking well-designed structures...

The deeper I dig into Rust and the more disgusted I became, personal opinion only.

Cheers,
bzt

That reference page is not designed to specify the Rust ABI because that page is a part of the Rust language reference, not a reference on the compiler. That page talks about methods to influence which ABI the compiler uses. If you don't tell it which ABI to use, it defaults to extern "rust", which is unstable and undefined because, well, you didn't tell it what to use, so it assumes you don't care -- and that's an adequate assumption. (Also, I find the reasons Google doesn't use Rust to be kinda odd and nonsensical. I suspect the primary reason is because, as they say, none of their developers use Rust. However, they do note that "Rust is approved for use throughout the Fuchsia Platform Source Tree", with the only exception being the kernel. So I'd say that criticism of yours is just nitpicking.)
Edit: Their actual reason for not doing this is because "[T]he Zircon kernel is built using a restricted set of technologies that have established industry track records of being used in production operating systems." The reason that you listed is just a con (and an unusual one at that) and does not, I suspect, actually influence the decision. If Google were working purely off of a "pro vs. con" ratio, Rust would be used. So it has more to do with the fact that Rust hasn't been used (yet) in production OSes, and none of their developers use it, than the fact that the language has selected a "unusual design point", whatever that means (because you have to admit that that reason is incredibly ambiguous and could mean any number of things). Perhaps instead of being "disgusted" by the language, you should actually try using it and do more research than you've done on it?

Ethin wrote:That reference page is not designed to specify the Rust ABI because that page is a part of the Rust language reference, not a reference on the compiler.

The URL is "reference/abi.html", and the page's title is "Application Binary Interface (ABI)", yet it's not about the ABI. You can try to find as many excuses as you want, but this is just lame.

Just for the record, languages do define the ABI, like Pascal vs. C on the same architecture with the same executable format use different calling conventions (and Ada is using a third, C++ a fourth kind). No matter if you use GNU gcc or LLVM CLang (so no, it's not the compiler that defines these). It's only logical to expect ABI specification in a programming language's documentation on a page called "Application Binary Interface (ABI)".

Cheers,
bzt

bzt wrote:

Ethin wrote:That reference page is not designed to specify the Rust ABI because that page is a part of the Rust language reference, not a reference on the compiler.

The URL is "reference/abi.html", and the page's title is "Application Binary Interface (ABI)", yet it's not about the ABI. You can try to find as many excuses as you want, but this is just lame.

Just for the record, languages do define the ABI, like Pascal vs. C on the same architecture with the same executable format use different calling conventions (and Ada is using a third, C++ a fourth kind). No matter if you use GNU gcc or LLVM CLang (so no, it's not the compiler that defines these). It's only logical to expect ABI specification in a programming language's documentation on a page called "Application Binary Interface (ABI)".

Cheers,
bzt

Alright, then. If your so sure, kindly point me to the section in the Ada reference manual or the ISO C/C++ standards that talks about the ABI, would you? I think you'll find that nowhere. So tell me, then, why the rust reference -- which, might I remind you, is a language reference, not the reference documentation to any implementation of the language (if you want that, go look at the Nomicon) -- should specify the ABI?
Also, that page explicitly says, "This section documents features that affect the ABI of the compiled output of a crate.
See extern functions for information on specifying the ABI for exporting functions. See external blocks for information on specifying the ABI for linking external libraries." Therefore, either (1) you didn't bother reading the page and just tried to find stones you could throw, (2) your grasp of the English language is a lot less than you'd have us believe, (3) you have reading comprehension problems, or (4) your being deliberately and knowingly obtuse.

Ethin wrote:Alright, then. If your so sure, kindly point me to the section in the Ada reference manual or the ISO C/C++ standards that talks about the ABI, would you?

They don't have any page in their documentation titled "Application Binary Interface (ABI)", but Rust does...

BTW, Ada allows multiple ABIs, and the spec is here (titled "Interfacing Aspects").
The ABI for x86-64 and the C language for example is here, differences to the C++ ABI are explained in section 9.3. Another popular ABI for the x86-64 and the C language is documented here. (Note how both specifications express explicitly that they are specifying an ABI for the C language only, and nothing else.)

Let me make this extremely simple for you: in kernel development it's an everyday, pretty common task that you have to call a function implemented in Assembly (memcpy or msr for example), or that you have to call a higher-level function from Assembly (calling common interrupt handler from an ISR for example). How can I do these with Rust? (Take time to understand that in this question I haven't used anything x86 specific, it is a general question. How can I call Rust from an IDT routine or VBAR routine for example? With C, it's pretty obvious and straightforward how no matter if we are talking about x86 or ARM for example.)

Cheers,
bzt

bzt wrote:

Ethin wrote:Alright, then. If your so sure, kindly point me to the section in the Ada reference manual or the ISO C/C++ standards that talks about the ABI, would you?

They don't have any page in their documentation titled "Application Binary Interface (ABI)", but Rust does...

BTW, Ada allows multiple ABIs, and the spec is here (titled "Interfacing Aspects").
The ABI for x86-64 and the C language for example is here, differences to the C++ ABI are explained in section 9.3. Another popular ABI for the x86-64 and the C language is documented here. (Note how both specifications express explicitly that they are specifying an ABI for the C language only, and nothing else.)

Let me make this extremely simple for you: in kernel development it's an everyday, pretty common task that you have to call a function implemented in Assembly (memcpy or msr for example), or that you have to call a higher-level function from Assembly (calling common interrupt handler from an ISR for example). How can I do these with Rust? (Take time to understand that in this question I haven't used anything x86 specific, it is a general question. How can I call Rust from an IDT routine or VBAR routine for example? With C, it's pretty obvious and straightforward how no matter if we are talking about x86 or ARM for example.)

Cheers,
bzt

You just exactly proved my point. The C, C++, and Ada standards make no reference to ABIs because that's *irrelevant* to the language itself. There are interfacing aspects, sure, but that's still not an ABI specification. And you completely and utterly ignored what I said at the end of my post as well. The rust reference (in particular that page you linked to) explicitly states:

Rust Reference wrote:See extern functions for information on specifying the ABI for exporting functions. See external blocks for information on specifying the ABI for linking external libraries.

I don't know how I can make that any clearer for you. The Rust developers have gone out of their way to provide incredibly well-written documentation that answers *all* f your questions if you wouldn't try to troll and find problems where there were none. Your an OS developer and someone who's written code in (most likely) many different languages; I seriously can't fathom how you've managed to get as far as you have when your so willing to create problems that don't actually exist, and then to claim that its a problem with whatever you've read or a problem with the tool/language/documentation your using and it couldn't possibly be the fact that your just unwilling to read things a bit more carefully.

bzt wrote:Let me make this extremely simple for you: in kernel development it's an everyday, pretty common task that you have to call a function implemented in Assembly (memcpy or msr for example), or that you have to call a higher-level function from Assembly (calling common interrupt handler from an ISR for example). How can I do these with Rust?

You tell the Rust compiler to use the C ABI. It's not rocket science.

I should have thought the reason that Google don't like Rust is blindingly obvious. They have their own language to push. More interesting is why Microsoft are so keen on Rust.

iansjack wrote:More interesting is why Microsoft are so keen on Rust.

Probably has something to do with the fact that it is becoming impossible to find and hire competent C++ programmers. C++ is becoming the new COBOL (if it's not already).

Ethin wrote:You just exactly proved my point.

Nope, you just proved you can't read.

Ethin wrote:The C, C++, and Ada standards make no reference to ABIs

They are very specific about having an ABI and that it's specified elsewhere. And what does SysV ABI and MS ABI specify if not those? Here's the quote again:

Note how both specifications express explicitly that they are specifying an ABI for the C language only, and nothing else.

It is a fact that C language has an ABI, it is specified well, while all that Rust has is a joke.

Ethin wrote:There are interfacing aspects, sure, but that's still not an ABI specification.

They never said that it was! It's the other specification I linked that has the title "Application Binary Interface", and indeed it's about registers and stack layouts. On the other hand Rust did claim that it has the ABI spec, by calling the page "Application Binary Interface (ABI)", and btw there's no other document by that name. You do realize the difference, right?

Ethin wrote:And you completely and utterly ignored what I said at the end of my post as well. The rust reference (in particular that page you linked to) explicitly states:

Rust Reference wrote:See extern functions for information on specifying the ABI for exporting functions. See external blocks for information on specifying the ABI for linking external libraries.

I did not ignore it. I said that that tells absolutely nothing about the actual ABI, which is 100% correct. Describing how to use the "extern" keyword isn't the same as specifying the in-out registers and stack layout (which is, by definition what binary interface specifies). Using keywords like "extern" and "external" are part of the API (as I've already said).

Ethin wrote:I don't know how I can make that any clearer for you.

It is very much and utterly clear to me that what Rust has by the name "ABI" isn't the binary interface at all. That's the truth. Nothing you can say would change that fact.

For your information, the OP question was:

pvc wrote:How is Rust ABI on x86, AMD64, ARM32 and ARM64 defined? Is Rust ABI stable? How registers are used? What is stack frame layout? How does name mangling work in Rust?

Here I ask you again: where is a link to a Rust ABI specification that talks about the registers and stack layout? It isn't the one that's falsely called "Application Binary Interface (ABI)", so where is it?

iansjack wrote:You tell the Rust compiler to use the C ABI. It's not rocket science.

If you must resort to the C ABI, then why don't you use that ABI in Rust in the first place? Why is there a need for an unstable Rust ABI at all? See what I mean? What if you take a year break (like many OSdevers do) and you want to make a small change in your kernel a year from now? Do you have to recompile EVERYTHING because the latest compiler can't link properly with your one year old Rust libk? That's hilarious.

Anyway, C is still the best language for kernel development, neither Go nor Rust is a match by far. I'm looking forward the day when Rust becomes the new COBOL, or the new Java, and I'm 100% sure it's going to happen in my lifetime. Now it's new and hyped, but that will pass pretty soon. I'm also 100% sure C will be still around long after I'm gone.

Cheers,
bzt