Hacker News Reader

Comment by outside1234 | Hacker News Reader

Why would someone want this? (Honest question)

The main source of interest for GCC Rust is because GCC targets more platforms than LLVM. A partially-overlapping interest is using Rust in Linux: Linux targets non-LLVM platforms, but is also deeply tied to GCC and Rust-for-Linux would have a lower barrier to entry if it doesn't require a second toolchain.

Long-term, it's considered a strong signal for the health and viability of Rust if it's not strictly tied to one implementation.

Yup. We have microcontrollers that we'd like to write rust on, but we can't because llvm doesn't support the architecture.

A question for curiosity since I don't know much about llvm and specifically the architecture. Does LLVM not support architectures because there is some barrier, or a higher barrier than GCC? And GCC makes it easier to support some architectures or is it just as easy to add the support to LLVM but no one does it because GCC already supports it?

The vendor sometimes does this and GCC is much more standard in the embedded space. And crucially, it's required to be open source.

For example, for arm-none-eabi, ARM provides a GCC toolchain (https://developer.arm.com/Tools%20and%20Software/GNU%20Toolc...) but makes you purchase the LLVM-based one (https://developer.arm.com/Tools%20and%20Software/Arm%20Compi...). Now I'm fairly certain there's an open-source way to target ARM microcontrollers with LLVM but you can't download it from ARM...

That's so strange. Rustup does ship with support for baremetal EABI ARM:

    $ rustup target list | grep arm | grep none
    armebv7r-none-eabi
    armebv7r-none-eabihf
    armv7a-none-eabi
    armv7r-none-eabi
    armv7r-none-eabihf

... which means the publicly-available open source version of LLVM also supports it.

Sure I bet it does, otherwise Rust wouldn't work on perhaps the most common microcontroller target, and I know it does. I don't know if there are secret sauce bits ARM adds to their version, or if there are differences in hardware support or anything like that. (I use gcc on these targets...have never looked into using Clang/LLVM on them).

edit: looking into this more, yes, upstream clang/llvm should work, though it doesn't include a C stdlib for this target (of little import to Rust, presumably), so you'll have to find one (e.g. by taking it from the GNU toolchain) if you want to use a C stdlib on embedded. Who knows what secret sauce armclang adds to clang...

Where's the "purchase" part there? I see a download link, and it seemed to download the toolchain? I don't have any projects lying around to actually try it out, but it looks complete?

I briefly looked at the license and it seems that if you're getting it for free, then its all good, you just get no support.

(I only write Rust on ARM and so am unfamiliar with the various toolchains they offer, honestly.)

Ah, ok I saw this table: https://i.imgur.com/5ofzjC3.png and that trying to download required an account (which is not true for the GCC toolset) and assumed they'd make you pay something. But maybe they just try to trick you into thinking you might have to... (or I am easily fooled).

edit: My legalese is not great, but isn't the the license saying that you can't legally distribute software compiled with the LLVM-based ARM tools if you obtained it for free? Obviously the gcc-based tools can't have such restrictions.

    3.2 NON-COMMERCIAL USE AND FREE OF CHARGE LICENSES: 
     ...
    (b) if you are receiving a Non-Commercial Use License or version (as applicable) of the Arm Tools: 
    (i)  you and your Permitted Users may use the Arm Tools for internal use only; and 
    (ii)  you are not permitted to distribute or sub-license (A) any part of the Arm Tools, or (B) Your Software,
          Your Hardware, or Your Reports developed under this License using the Arm Tools. The Arm Tools shall be
          used only by you and your Permitted Users, and you shall not (except as otherwise authorised in writing by Arm) 
          allow any other third party whatsoever to use the Arm Tools. 

    For the avoidance of doubt, if you are receiving a Non-Commercial Use License and the license is provided to you free of
    charge, the restrictions in both sub-clauses (a) and (b) above will apply to your use of the Arm Tools.

additional edit:

Here's what happens when I try to run armclang:

     $ armclang
     armclang: error: Failed to check out a license.
     The license file could not be found. Check that ARMLMD_LICENSE_FILE is set correctly.

I did not bother to figure out if there's a way to get a license without paying (though I would likely qualify for a non-commercial license as an academic user, but it seems like a pain).

There’s that but but there’s also the “got it for free” thing above that; seems distinct from a “noncommercial license.”

But who knows, honestly they make this stuff as confusing as possible, it seems.

It's a mixture of problems.

GCC targets more platforms than LLVM, that much is true. But beyond that, it's pretty common in the microcontroller world for a vendor to release their own specially patched version of GCC blessed for a given platform. They simply aren't doing that for the LLVM.

Those blessed GCCs aren't often seeing the hacks merged upstream.

Here's one such example:

https://www.ti.com/tool/MSP430-GCC-OPENSOURCE?keyMatch=gcc&a...

But that's not an argument for GCC-RS, that's an argument for rustc_codegen_gcc. The purpose of GCC-RS is a) licensing and b) fracturing the community to stabilise the language spec, something I'm very doubtful over for at least a few more years.

Note that for providing more platform support, there is also rustc_codegen_gcc which just replaces LLVM with libgccjust but keeps the rustc frontend.

Competition.

GCC had laughably bad error messages before LLVM caught on. Even then, LLVM generated terrible code compared to GCC. There's a similar competition going on with open source linkers (which are finally going multi-threaded).

Both compiler toolchains currently blow pre-LLVM GCC out of the water (and GCC development has noticeably accelerated since LLVM came out).

I'm not sure which one is better at which C++ thing these days, but I'll bet GCC Rust will beat LLVM Rust at some important things in a few years (and then vice versa).

Similar story to Vim/Nvim and maybe partly OpenSSL/LibreSSL. Forking (not all technically forking) is good sometimes.

And now clang is lagging in C++20 support, and modules will come in 2 to 3 years as per roadmap (right after C++23 is done), while VC++ already has them, and GCC head is catching on relatively fast.

Another angle is that GNU wants this, because they want GCC to stay relevant and competitive. Rising popularity of LLVM-only Rust gives advantage to their competitor.

No worries, it will keep releavant, now that Apple and Google apparently took out their support from clang, and most other vendors that benefit from MIT aren't that keen into pushing C++ changes upstream, clang is getting a nice third place in C++20 support.

Apple Clang is already a completely different beast than upstream, right? At least the version numbers are nonsensical unnecessarily complicating feature support checks in my experience as someone who doesn't own any Macs but writes software that others insist on trying to compile on a Mac...

Yes, hence having its own column on cppreference, or a special flavour of bitcode for watchOS.

In what concerns Apple, I think they mostly care about the C++ support needed to keep LLVM going, the C++14 based dialect for Metal Shading Language, and the subset used across IO and DriverKit.

For everything else there is Objective-C and Swift.

Then Google apparently drop off clang after the ABI break votes didn't went the way they wanted, so they are now focusing on Abseil, and their style guide is anyway quite restrictive.

So now we are in this ironic situation, that VC++ from all compilers is the one with best C++20 support, closely followed by GCC, and then there is clang and the other lesser known ones still lagging in C++17 and earlier.

Yep, the perma-frozen ABI decision sounded the death-knell for C++. Basically the committee committed collective hara-kiri with that decision. Thou Shalt Not Progress!

It's so extraordinarily, mind-bogglingly stupid. But I guess it is time for the ageing C++ queen to pushed out of the mortal coil and let Princess Rust grab her long-overdue system crown.

I don't know, ABI changes are super annoying.

Princess Rust has no proper throne on the kingdom of binary libraries.

Without ABI change C++ is trapped forever with bad decisions. In some cases these are decisions which were bad twenty years ago and are still bad today but should be fixed, in other cases these are decisions which were probably the right call twenty years ago but now you'd choose differently.

Did you know on MSVC a std::mutex is so huge it needs more than one cache line ? Obviously Microsoft aren't stupid, they know how to fix that... but it would change the ABI so they can't touch it.

And so the Zero Cost Abstraction promise "Don't pay more than it would cost if you did it yourself" becomes "Eh, just do it yourself" everywhere - C++ programmers learn to hand roll all the basic stuff they need, because ABI stability has ensured the standard library mechanisms are slow, or bloated, or both.

Doesn't matter, binary libraries are a big deal for many businesses, regardless of ABI constraints in C and C++ languages and compilers.

Either Rust wants to play on that field, or it doesn't.

Microsoft has broken their ABI plenty of times, and VS vNext might be when the next break will take place, which was initially planned for VS 2022.

Bashing C and C++ ABI issues on HN will do very little for those businesses to adopt source code distributions.

You can write and use binary libraries in Rust, you're just restricted to using the stable C ABI to interface across separately-built components. Spoiler: You'll want to do this anyway, because it's required for any sort of C-compatible FFI regardless of language.

Nope, Windows C++ compilers have supported DLLs since Windows 16 bit days.

Some famous C++ frameworks that ship as binaries are OWL, VCL, FireMonkey, MFC, ATL, WinUI.

And WinRT has improved upon classical COM ABI to provide even more data types.

On Windows there is a component market selling libraries for those ecosystems.

Then we have middleware vendors for game consoles as well.

Maybe this isn't a market Rust community cares about and that is fine.

This is not the only case. It harms not only performance, but also conformance, e.g. https://developercommunity.visualstudio.com/t/unable-to-move....

Microsoft is stupid enough since the first decision of the implementation impacting the ABI is made. There was no one enforcing such bad decisions shipped into the productions at the very beginning. Both libstdc++ and libc++ have more flexible rules to preventing ABI breakage.

On the GCC side, there are no plans to stop supporting building applications using Clang and libstdc++ (that is, using the libstdc++ installed headers and the GCC-built libraries/shared objects). Therefore, a question mark next to libc++ doesn't necessarily threaten the long-term viability of Clang as a C++ compiler. (I assume your Abseil comment is actually about libc++.)

My Abseil comment is about where Google now rather sees their employees spending time on C++ libraries for them.

At least from the comments I sometimes see flying by on Reddit.

I didn't see this mentioned in any replies, but I think another reason why this is wanted is for Rust in the linux kernel development. If Rust can compile using GCC tooling, it should be easier to integrate into the build process for the Linux kernel. As it stands now, if Linux kernel development allowed Rust in areas of the kernel outside of modules and drivers, you need the GCC tool chain to build the kernel and the llvm toolchain. So it also meets a requirement, or at least greases the wheels, for the possibility of getting Rust into the Linux kernel.

And while you can link a gcc-compiled kernel with llvm-compiled rust, apparently you lose some link-time optimization, and with that control-flow integrity [1]. That's a potential security concern for the kernel, in addition to the usability issues of using two toolchains.

1: https://www.cs.ucy.ac.cy/~elathan/papers/tops20.pdf

rustc_codegen_gcc will solve the same problem. I would expect it to be possible to do LTO and CFI across rustc_codegen_gcc and gcc-compiled C or C++ code.

GCC already has compiler front ends for Fortran, Ada, Go, and formerly Java. Adding another language, especially one as popular as Rust, couldn't hurt.

Huh, I didn't realize that

A common misconception is that GCC stands for GNU C Compiler, but it stands for GNU Compiler Collection. Perhaps why you did not realize ;)

I didn't know that either! And I've even used it before, haha

GNU C Compiler was the original name. A lot of us probably never bothered updating our mental acronym tables.

You mean to tell me that the acronym settled in your head between March and December 1987 and you never reconsidered since then?

Nope. It settled in my head before it was renamed in 1999: https://gcc.gnu.org/wiki/History#Reunification

But I assume the name of the gcc binary stands for GNU C Compiler?

also D and Objective-C!

Multiple implementations of a standard help shine light into dark corners.

Indeed, but I think they should first create a standard?

If not a standard, then at least a specification. This discussion is from 2020, so I'm not sure if it's still up to date:

https://users.rust-lang.org/t/where-is-the-rust-language-spe...

"For the most part though, rustc itself is the spec" - so, for implementing the GCC frontend, read the current LLVM frontend really carefully and do everything the same way? And try to keep up with all the changes which will inevitably happen in the LLVM frontend while you are implementing the GCC frontend?

Integration-style tests are a good tool here. Given a set of programs in the target language with certain expected behavior on the reference compiler, you check that compiling and running with the second compiler produces the same behavior.

> so, for implementing the GCC frontend, read the current LLVM frontend really carefully and do everything the same way?

At a high level, this is correct: https://github.com/Rust-GCC/gccrs/wiki/Frequently-Asked-Ques...

> If gccrs interprets a program differently from rustc, this is considered a bug.

I don't believe they are only reading the frontend, but using the reference first, then looking to the implementation second, and asking a lot of questions along the way.

Rust already has stable standards. There's Rust editions 2015 (1.0), 2018 (1.31.0), and 2021 (1.56.0).

Unfortunately that's not quite the same thing as a standard in the sense that is meant here. A 'standard' is a written document that explains how the language should work. A standard that just says "the compiler is correct if it compiles code the way that rustc 1.xy does" is technically unambiguous in that it provides a procedure by which a compiler author can check their work, but leaves quite a bit on the table and is probably the wrong goal to aim at in the long term, even if it enables forward progress for now. (For example, we know rustc contains bugs; do we want gcc-rust to include all the bugs, or should it differ from rustc in that respect? Which behaviors are bugs, which are undesired but accepted quirks of the language, and which are intentional? For that matter, it's unreasonable to expect gcc-rust to produce binaries that are byte-for-byte identical, so what other mechanism should be used to determine equivalence?)

(btw, there's also https://doc.rust-lang.org/reference/)

Correct.

With an ideal standard document that describes the language, someone could build a compiler for the language from scratch and it should behave correctly. See https://en.wikipedia.org/wiki/Programming_language_specifica...

Some example standards:

C: https://www.open-std.org/jtc1/sc22/wg14/

ECMAScript (Javascript): https://tc39.es/ecma262/

C++: https://isocpp.org/std/the-standard

Scheme: https://schemers.org/Documents/Standards/

Ada: http://www.ada-auth.org/standards/ada12_w_tc1.html

For Rust, Ferrous Systems is working on the Ferrocene Language Specification to formally document the Rust subset that Ferrocene will use.

https://ferrous-systems.com/blog/ferrocene-language-specific...

https://ferrous-systems.com/ferrocene/

There are various reference documents for Rust, but how do you know if they're complete and accurate without creating a working interoperable implementation?

ISO will stamp any fantasy like OOXML, but that doesn't mean the standard is useful.

Having another implementation first actually helps create a good standard, by highlighting things that are implementation-specific assumptions.

Another reason besides platform support, is bootstrapping and verifiable builds. rustc can only be built by a recent rustc, so it is a pain to bootstrap from source if you don't want to trust a big binary.

https://github.com/thepowersgang/mrustc is already providing that; it targets 1.54 right now, which is farther along than this project (though obviously that may not be always true in the future).

Ah, I didn't realize it could do 1.54 now, neat! Last time I looked at the state of bootstrapping rustc in Nix and Guix, mrustc could only do 1.20-something, and you had to build a dozen rustcs to get to the current version. Does mrustc keep up now though? With 1.63 in beta it's still quite a chain to build from 1.54.

A significant chunk of this drive is for the Rust/Linux kernel project.

Gcc has more stable hardware targets than llvm, for starters.

Note that there is a separate project to use the GCC backend with the Rustc frontend. At least in the short-term, that project will be the better approach to providing the benefits of more hardware support, since it will be more complete and compatible with the rustc/llvm compiler.

The main benefit of a GCC front-end is to move Rust beyond a single vendor, and shakeout ambiguities in the (informal) language specification.

It is also useful for building rustc from source without any rustc binaries, although mrustc (a Rust to C transpiler) was supposed to be good for that too.

alternate architectures; plurality

Isn't this already addressed by the GCC backend for rustc? (Via libgccjit)

Reply on news.ycombinator.com