LWN: Comments on "Rust adopting Ferrocene Language Specification"

Shared libraries can, and probably will, happen

farnz — Mon, 14 Apr 2025 08:52:53 +0000

I meant that glibc's accidental guarantee (Hyrum's Law) that memcpy would work as intended by the software developer on overlapping regions as long as the destination address was numerically lower (when considered as an integer) than the source address was a bug. That wasn't a promise made by anyone (glibc, CPU designers, ISO, POSIX), just an accident - and anything that assumed it was designed resulted in the combination being buggy.

And architectures are a component of a platform; I'm using the more specific term because I'm not just referring to a specification, but also to a complete family of implementations of that specification, where things that are not defined by the architecture are implicitly defined by the implementation. Versioned symbols are a good example of the gap here; the symbol defined in the architecture is always memcpy, even though the platform I'm using has memcpy@@GLIBC_2.14 and memcpy@GLIBC_2.2.5 with memcpy being defined as an indirect function (an extension to the base architecture) that chooses a system-specific __memcpy* variant.

I no longer work somewhere where old software is relevant, so I no longer have the versioning script to hand; my recollection is that it was as simple as putting a __asm__(".symver …") statement in our common header file, so that everything that used that linked the older symbol version. For example, for memcpy, I just had to put __asm__(".symver memcpy,memcpy@GLIBC_2.2.5"); in the header file, which meant that everything of ours that referenced memcpy implicitly picked up the older version.

Shared libraries can, and probably will, happen

anton — Sun, 13 Apr 2025 17:35:52 +0000

Thanks, interesting. I spent too much time reading through the flame wars about the topic without coming across the information about the actual issue at hand; I dimly remember reading about doing the negative stride on Bobcat, but now that I think about it, the flame war was in 2010, and Bobcat was only launched in 2011.

So the stride direction was not only based on the actual hardware, but also on the specific bits in the addresses of source and target. This makes it even harder to find an overlap bug with testing.

Shared libraries can, and probably will, happen

anton — Sun, 13 Apr 2025 17:15:25 +0000

I'm not calling the implementation of memcpy buggy

You certainly wrote "someone who linked against an older, buggy version of glibc to get the behaviour they expect". What did you mean with that?

As for building binaries that run on older targets than the build system, I have spent some time on trying to do the symbol versioning etc., but eventually gave up. If you have a recipe for doing it, I would be interested in reading about it, especially if it can be used across architectures (which you seem to be calling "platforms") and has at least an escape hatch for those cases where one does not link with glibc.

Shared libraries can, and probably will, happen

dvdeug — Sat, 05 Apr 2025 16:34:15 +0000

Then stop writing code in C. This isn't really an arguable case; memcpy doesn't work on overlapping memory, and memmove does. If you don't care about the speed improvment, use memmove. Unlike some of the other issues, like integer overflow, this is explicit and universal.

If you want to know if your program works on NetBSD for the Nintendo Wii, no amount of testing on Linux/AMD64 will provide the answer. Different CPUs work differently, and different OSes provide different libcs and support different features.

A VM like the JVM or .Net can mask some of the problem. Even better, write it for the SNES or Commodore 64, or some other monoculture system with tightly timed emulators. But real world systems, especially under a language like C, aren't going to be so nice as to be testable one place and run anywhere.

Shared libraries can, and probably will, happen

kreijack — Thu, 03 Apr 2025 16:09:06 +0000

> To make something like what you are asking about feasible Rust would have accept the burden of supporting old version of data structure layouts.

> And that's not something Rust compiler developers want to support.

I think this is the point. It is not a technical issue, is a an unwillingness of be constrained to an stable ABI.

Shared libraries can, and probably will, happen

excors — Thu, 03 Apr 2025 11:41:20 +0000

It wasn't just "some glibc developer ... on some CPU", it was an Intel engineer (who I assume had access to expertise on how to make the most of Intel's hardware) making large improvements across multiple microarchitectures (not just from going backwards, but that was part of it):

> This patch includes optimized 64bit memcpy/memmove for Atom, Core 2 and Core i7. It improves memcpy by up to 3X on Atom, up to 4X on Core 2 and up to 1X on Core i7. It also improves memmove by up to 3X on Atom, up to 4X on Core 2 and up to 2X on Core i7.
(https://sourceware.org/git?p=glibc.git;a=commit;h=6fb8cbc...)

From the discussion on old bug reports, there's an explanation that backwards copying helped avoid false read-after-write dependencies on 2010-era Atom: the CPU only looks at the LSBs of the src/dest addresses, and may think they're overlapping (preventing reordering of accesses) when they really aren't. The code compares the low byte of the addresses to decide whether to go forwards or backwards, so the CPU can easily tell there's no overlap. (https://lists.freedesktop.org/archives/pixman/2010-August... - that was for Pixman but the glibc patch seems to do the same thing.)

Shared libraries can, and probably will, happen

Wol — Thu, 03 Apr 2025 10:55:43 +0000

3. Explicitly specify/comment what does and doesn't work, and hope other programmers bother to read it ...

Cheers,
Wol

Shared libraries can, and probably will, happen

farnz — Thu, 03 Apr 2025 10:23:47 +0000

The core problem is that some change is bad, and some change is good, and in a testing-only world, you have no way to tell which change is good and bad without fully retesting. That's just the nature of the beast.

As a result, arguing that some forms of change are bad because they result in "tested code" failing, but other forms of change are good because they don't is just another way of saying "I want the results of doing full retests and fixing all bugs that you find this way, or of proving my code correct instead of testing it, but I don't want to do any of that work".

If you're sticking to just testing things, you have two reasonable choices:

Lock everything down, and do a full retest and fix new bugs whenever you update things. This is what is done in safety-critical software.
Accept that testing can't demonstrate that code is bug-free, and fix bugs whenever they show up. This may be in your code, or may be in the environment - you literally don't know until you've found the bug.

You cannot, by testing alone, confirm that your binary is bug-free and thus that any bugs that show up when the environment around it is changed are bugs in the environment; that's literally not how testing works. Instead, if you're going down the testing model, you either lock everything down (zero changes), or accept that when things change, bugs that your tests previously did not find are now exposed.

Shared libraries can, and probably will, happen

farnz — Thu, 03 Apr 2025 10:17:36 +0000

I'm not calling the implementation of memcpy buggy; I'm calling the code that assumed that memcpy could be used on overlapping regions buggy. Glibc has a shim in place so that buggy code that makes the assumption that memcpy is just a "faster" memmove continues to work.

When I say the i386 platform, I mean the platform defined by the ELF i386 psABI and implemented by CPUs including the AMD Ryzen 7 7840U I'm using right now, not the specific Intel 80386 CPU family. If you limit yourself to the i386 platform without SIMD extensions, then there's no significant performance advantage to any particular stride direction. But that's specific to that platform, where the fastest way to do short copies is via the 32-bit integer registers, and longer ones via REP MOVS. On other platforms (e.g. those with AVX-512, or non-x86 platforms), other strides are advantageous.

And, for example, Bazel can be configured so that the entire platform is part of the build scripts you're using; such a toolchain setup will link against the platform that's in the build scripts, even though you'll then run the binaries on older systems. Similarly, I've used linker script snippets very successfully with a custom GNU Make based build system (GCC as compiler), to ensure that I could build on latest Fedora while still having my binaries run on a target system; you say it's "not viable", but my experience directly contradicts that.

Shared libraries can, and probably will, happen

anton — Thu, 03 Apr 2025 10:16:09 +0000

Luminaries like Dijkstra have warned against the limitations of testing since the dawn of computing; and Dijkstra actually did something about it, by teaching programming in an unimplemented programming language, thus making the programs untestable.

Nevertheless, testing is still the most common way to determine if a program is buggy, so any decision has to be evaluated in the light of this reality. And if we evaluate the decision of glibc to use different stride directions for different CPUs in this light, this decision is a fail. And the ensuing flame war shows this.

The rest of your posting looks like whataboutism to me, but anyway:

Code is rarely timing-sensitive, but if it is timing-sensitive, dynamic linking is the least of its worries: multi-tasking, different CPUs, different and varying clock speeds on a given CPU, cache misses etc. cause timing to vary a lot.

As for the idea that locking down versions of everything helps: This is an idea that proprietary software exercises, and that the fans of undefined behaviour advocate for dealing with the problems they are causing. But we develop free software, and that approach is impractical. Nevertheless, we use testing as the main method for determining whether our software has bugs, and it works; yes, a few bugs are found after the release, but that's usually because testing cannot show the absence of bugs, not because of timing or software versions.

Shared libraries can, and probably will, happen

Wol — Thu, 03 Apr 2025 10:14:41 +0000

> This is the core problem that anything based on testing has - if anything changes, then the tests are invalidated, and you need to retest, since you don't actually know for sure why a given test passed.

And if programmers don't have a spec - or even worse ignore it - then you get carnage like the aforementioned memcopy.

Or Excel. The hoops I have to jump through to keep numeric data in string format because Excel will autoconvert it then complain it's the wrong format. Or users - retrieving a numeric value with a "case" statement from SQL, making the "else" clause return "error" and crashing all the logic that assumes that a number is, well, a number ...

Cheers,
Wol

Shared libraries can, and probably will, happen

anton — Thu, 03 Apr 2025 09:45:44 +0000

I mean, memcpy is literally defined as using any access pattern that the C library chooses.

Exactly. And that includes positive stride. So why do you call this implementation of memcpy() "buggy"?

As for "the i386 platform", I assume you do not mean the i386 CPU (introduced in 1985, and discontinued 2007), but the instruction set (aka architecture) that is implemented by Intel and AMD CPUs to this day (in comptibility and legacy modes on most CPUs since 2003). As it happened, some glibc developer found that negative stride was faster on a benchmark he used on some CPU (which probably was not an i386), and the rest has been described above and below. The effect is that you can compile and test a program on one CPU, and the binary works as intended, but on a different CPU with the same instruction set, the binary does not work as intended.

And that last bit isn't a limitation of symbol versions, per-se, but rather because the toolchain you're using is designed for one-way compatibility only

Is there a toolchain that does not have this limitation? Not that I know of. So introducing a new symbol version for addressing a non-bug as was done for memcpy() does not just cause problems for those people who want to compile old, previously working programs with some hidden assumption that did not show up on testing. They also cause problems for people who compile programs where any memory access order of memcpy() works, who want to produce a binary that also works on older systems.

As for using linker scripts, yes, that's what I tried, and found not to be viable.

Shared libraries can, and probably will, happen

farnz — Thu, 03 Apr 2025 09:12:08 +0000

If all correctness is approximated by testing, then dynamic linking of any form (including the system call interface) is an absolute disaster zone, and to be completely avoided, since you may depend on things like timing for correctness, and changing code on any side of an interface can result in a change that affects correctness.

This is the core problem that anything based on testing has - if anything changes, then the tests are invalidated, and you need to retest, since you don't actually know for sure why a given test passed. As a result, you need to test on locked down versions of everything, and redo all tests when anything changes - and in the safety sphere (with qualified compilers, libraries etc), that's exactly what you do when you recertify; you show that the code is intrinsically only capable of doing certain things based on the source code, and you test that the thing it does is correct. When you change any code, you have to recertify - you can't rely on "compatibility", but have to redo everything.

This is the reality we live in; you can't change anything about the processing environment and expect your tests to remain valid.

Shared libraries can, and probably will, happen

farnz — Thu, 03 Apr 2025 09:09:19 +0000

I mean, memcpy is literally defined as using any access pattern that the C library chooses. If you assume that it will always use a positive stride, then you're ignoring what the function is defined to do in favour of what one implementation does.

And it's defined that way for a reason, since the preferred direction of copy for a given platform is not the same as on all other platforms; on i386, there's a mild advantage to a positive stride, but that's because of how the i386 platform was specified. If you want to take that code and run it on a different platform (and the goal of C is to be portable, after all, it's not tied to Intel's 386 architecture decisions), then you need to support whatever those other platforms do - which can include a negative stride being better for memcpy, or, on some platforms, no fixed direction of copy for larger copies (since you make use of a memory→memory transfer engine that can complete the copies in any order). This is why memmove exists, too, where the library must DTRT on overlapping regions.

And that last bit isn't a limitation of symbol versions, per-se, but rather because the toolchain you're using is designed for one-way compatibility only; you can run binaries built on an older platform on a newer platform, but it's hard to explicitly request compatibility with an older platform. You need to use a suitable linker script on the GNU platform to tell it to use specific versions of symbols.

Shared libraries can, and probably will, happen

anton — Thu, 03 Apr 2025 09:03:17 +0000

By putting the redirect shim in place, people who depended on bug-for-bug compatibility with 2.13 or earlier got it, and people who build and test against later glibc versions get to see the new behaviour and fix it.

Only if the testing is done on the right CPU, one where glibc implements negative stride. On CPUs where glibc implements positive stride, testing will not detect that the program relies on a memcpy with positive stride.

And that's the problem with the attitude that a partial specification (i.e., one that does not define all behaviour) is the only thing that matters: It's an attitude for a world where every bit of software is formally verified, and it's incompatible with a world where correctness of software usually is approximated by testing. Many may wish for the former, but the reality is the latter.

Shared libraries can, and probably will, happen

anton — Thu, 03 Apr 2025 08:50:52 +0000

linked against an older, buggy version of glibc to get the behaviour they expect.

s/buggy/more featureful/g

A well-known example is the behaviour of memcpy(). Some working programs (that fans of undefined behaviour call "buggy" or worse) relied on memcpy() using a positive stride, which happened to be the case for glibc up to about 2009 (demonstrating Hyrum's law). Positive stride in mempy() is not at all buggy. Then some smart glibc maintainer decided that it is a good idea to use negative stride on some CPUs, so these existing binaries failed on those CPUs when dynamically linked with the new glibc. The fact that positive stride is not buggy is demonstrated by the fact that glibc still used positive stride on other CPUs.

The glibc people insisted on their righteousness in ~~breaking~~extracting demons from the nose of the existing source program, but backed down for existing binaries by providing the more featureful version of memcpy() with an old symbol version and the less featureful version for default linking.

A nasty consequence of these symbol versions is that I cannot compile a program on a new system and run it on an old system, except with static linking (and that has its limits); I have tried to work around that by trying to get the old versions of the symbols into the binary, but found no way that was really viable.

Next step : shared libraries ?

xorxornop — Sat, 29 Mar 2025 04:38:19 +0000

That is its intended use but it would be just as useful in defining a common ABI for shared library use, preventing having to drop down to a simple C ABI

Next step : shared libraries ?

pabs — Sat, 29 Mar 2025 02:32:25 +0000

That sounds like a cross-language ABI rather than an a stable ABI for Rust itself?

https://github.com/rust-lang/compiler-team/issues/631

Shared libraries can, and probably will, happen

khim — Fri, 28 Mar 2025 17:35:25 +0000

> If you could then run that in reverse and feed it to the compiler to say "this is the definition I want", you'd get a stable ABI. Is that possible?

Not possible and there are no plans to make it possible.

> when you're compiling your program that calls that crate, of course you need to import that ABI

That's precisely the issue: you can, of course, export such ABI. But there are no way to import it.

What one version of compiler produces the other version of compiler have to accept. And that's not technical issue, but a social one.

Simplest possible, yet realistic example:

#[repr(u8)]
enum Foo {
    BAR = 1
}

That's the simplest possible enum. It only have one possible value: 1. And we even enforce encoding: it would always be encoded as byte 1. Where the heck may incompatibility arise?

Easy: Rust 1.56.0 encodes None for Option<Foo> as 2, but Rust 1.57.0 switched to more efficient 0. Without providing any means of producing old behavior.

And… that's it. Without Option and Result idiomatic Rust is, essentially, not possible. Option and Result are everywhere in Rust APIs.

And you couldn't support them even with simplest, most primitive, types.

Full stop. End of story.

To make something like what you are asking about feasible Rust would have accept the burden of supporting old version of data structure layouts.

And that's not something Rust compiler developers want to support.

> But given everything else "magic" Rust does, this doesn't seem unreasonable?

As part of that “magic” what you are asking for was deemed to be infeasible. As in: explicitly rejected and unsupported.

crABI is an attempt to provide a subset of usable data structures where such guaranteed of exporting then importing would be provided for some useful subset of Rust. But it seems to became stalled.

Shared libraries can, and probably will, happen

farnz — Fri, 28 Mar 2025 15:48:54 +0000

The technical issues, once you have a stable ABI that you can point to, are relatively simple to solve.

The harder part is the social issue; someone has to commit to maintaining a stable ABI, and you need some equivalent of the shims that glibc comes with that allow someone who linked against an older, buggy version of glibc to get the behaviour they expect.

For example, glibc has a shim that redirects people who linked against 2.13 or earlier to memmove when they ask for memcpy; this is because they changed the behaviour of memcpy (keeping within the spec), and broke Adobe Flash Player. By putting the redirect shim in place, people who depended on bug-for-bug compatibility with 2.13 or earlier got it, and people who build and test against later glibc versions get to see the new behaviour and fix it.

Shared libraries can, and probably will, happen

daroc — Fri, 28 Mar 2025 15:29:20 +0000

Tooling to do this is definitely possible in theory; it's a matter of getting someone to write and maintain it.

Parts of this already exist: the aforementioned crABI, which will allow complex Rust types to be passed between shared libraries, and projects like cargo-semver-checks that can be used to check whether changes to a library accidentally impact its public API in a backward-incompatible way.

Rust's tooling already presents a pretty good user interface, but I do believe that there are more improvements to be made if someone cares to make them.

Shared libraries can, and probably will, happen

Wol — Fri, 28 Mar 2025 14:44:55 +0000

> or (once the second option is fully viable) you need to make sure that the stable ABI surface is specified and sufficient for users of a crate.

Naive question, but I would have thought you could have some way of exporting the ABI as a definition file from a library crate? If you could then run that in reverse and feed it to the compiler to say "this is the definition I want", you'd get a stable ABI. Is that possible?

And better, when you're compiling your program that calls that crate, of course you need to import that ABI, but that then means that you can enforce Rust rules across the interface, rather than just trusting the interface is safe like I presume you have to do when calling / being called from eg C.

Then of course you need some way of flagging that the internal ABI has changed in (possibly incompatible) ways to require a new definition export.

But given everything else "magic" Rust does, this doesn't seem unreasonable?

Cheers,
Wol

Shared libraries can, and probably will, happen

farnz — Fri, 28 Mar 2025 11:20:50 +0000

To say that "shared library in Rust will not happen" is a misrepresentation of the article's contents; she is writing about how Swift achieved arbitrary dynamic linking with ABI stability, where any Swift code can be dynamically linked with any future Swift code regardless of what language features you use. In Rust, the equivalent would be that you could dynamically link arbitrary modules or crates, without any up-front work on the part of the module or crate's author to make it possible.

There's at least two variants on "shared libraries" that are a lot simpler than the version Aria is writing about, though, and one of those exists today:

Shared libraries with fully unstable ABI. This requires that all Rust code is built with an identical toolchain; because Rust supports separate compilation and linking, a given toolchain must have a stable ABI. You can do this today, but every time you use a different toolchain to compile (which could be as trivial a difference as "I cross-build for RISC-V from x86-64, you cross-build from AArch64" - that's two different toolchains, even if the versions of all components are the same), you need to rebuild everything. However, for embedded use cases, where you control the entire build system and the final outputs, it's practical today.
Limit the API surface of a crate, and have a deliberately exported stable API that can also be a stable ABI with the help of something like crABI. This requires crate authors to do the sort of work that glibc's maintainers do, to have an ABI surface that they're deliberately keeping stable for the benefit of dynamic linking. This is also entirely possible with Rust; the only questions are "who's going to do the work to make this happen", and "how limited is the stable ABI" - right now, you're limited to the psABI, crABI aims to expand this a bit to interesting things like tuples, slices, and sum types (Rust enums).

The thing that will always differ from C and Swift, however, is that Rust dynamic linking isn't going to be something that works "by accident"; either you, as downstream, have to make sure you have a stable toolchain (first option), or (once the second option is fully viable) you need to make sure that the stable ABI surface is specified and sufficient for users of a crate.

Next step : shared libraries ?

xorxornop — Fri, 28 Mar 2025 09:45:31 +0000

The most relevant work that I am aware of is crABI

Next step : shared libraries ?

pabs — Fri, 28 Mar 2025 07:28:41 +0000

Rust has shared libraries, there is just not a stable ABI for them yet. There has been some progress on that, but nothing that I can see recently.

https://wiki.debian.org/StaticLinking#Rust

Next step : shared libraries ?

kxxt — Fri, 28 Mar 2025 05:40:36 +0000

It could happen but it would requires rebuilding all dependent binaries when updating the shared library. (Just like how Arch Linux packages Haskell applications: https://wiki.archlinux.org/title/Haskell)

https://www.kxxt.dev/blog/fully-dynamically-linked-rust-b...

Next step : shared libraries ?

Cyberax — Thu, 27 Mar 2025 22:34:13 +0000

Not quite true. There's a push to enable _some_ shared library code (and also more compact binaries), by using dynamic dispatch and some pre-monomorphized types.

Next step : shared libraries ?

firstyear — Thu, 27 Mar 2025 22:28:45 +0000

Shared libraries in rust will not happen. They will never happen.

Please read the following written by a rust developer who knows this topic deeply.

"How Swift Achieved Dynamic Linking Where Rust Couldn't" - https://faultlore.com/blah/swift-abi/

Next step : shared libraries ?

ballombe — Thu, 27 Mar 2025 21:16:23 +0000

Now rust is just missing shared libraries to achieve parity with C++.