Improved dynamic linking ABIs [LWN.net]

Improved dynamic linking ABIs

Posted Feb 21, 2025 10:45 UTC (Fri) by farnz (subscriber, #17727)
In reply to: Great fit for Rust by ras
Parent article: Rewriting essential Linux packages in Rust

You can say "not here, at this boundary conventional linker is all you need" already, by using the psABI (repr(C) and extern "C") instead of the unstable Rust ABI.

The issue right now is that the psABIs aren't that great for Rust and Rust-like languages; the crABI experiment is aiming to come up with a stable ABI that is suitable for expressing the things that you lose by saying "not here", such as Vec<u32>, since Vec is monomorphized over its type argument.

to post comments

Improved dynamic linking ABIs

Posted Feb 21, 2025 11:33 UTC (Fri) by ras (subscriber, #33059) [Link] (52 responses)

> Vec<u32>, since Vec is monomorphized over its type argument.

That's a good illustration. You want the benefits of the type checking that monomorphization provides, but without it effecting the code generated. You can write that sort of code in Rust, but as Vec<u32> demonstrates it would be near impossible to write it without the compiler telling you "hey, you can't do that here" because type checking is usually bundled with implied monomorphization.

Improved dynamic linking ABIs

Posted Feb 21, 2025 12:11 UTC (Fri) by farnz (subscriber, #17727) [Link] (51 responses)

And the issue is that, under the current Rust ABI, the layout of Vec<T> is not specified until after monomorphization - you literally don't know what order the capacity, length, and data fields are in, since without knowing what T is, you don't know whether the data field is one or two pointers in size - and Rust is allowed to split up the two halves of a "fat pointer" (one that's two pointers in size), and to elide any parts of the Vec that aren't used (e.g. eliding length because it's always the same as capacity).

crABI's role is to specify layouts such that knowing that Vec is two usize and either a thin or fat pointer in size depending on T means that you know how Vec<T> is laid out in memory for any known T, at the expense of preventing the compiler from applying optimizations that come from different layout.

For Vec, crABI is unlikely to give up much performance; it's just not big enough that completely removing 2 or 3 fields would make a difference. But it's possible that for other data types, this optimization will matter; hence crABI will be opt-in for quite a long time (although I can see it becoming the default for all items exported from a crate, eventually).

Improved dynamic linking ABIs

Posted Feb 21, 2025 22:43 UTC (Fri) by ras (subscriber, #33059) [Link] (50 responses)

> And the issue is that, under the current Rust ABI, the layout of Vec<T> is not specified until after monomorphization - you literally don't know what order the capacity, length, and data fields are in, since without knowing what T is,

I'm not an expert, but I'm guessing there are 3 things Vec has to know. Yes the size of an element and the capacity are two. The current length doesn't count because it's not encoded in the type. Neither of those two are particularly problematic.

The 3rd is one you didn't mention: drop. That is more difficult. C++ would use a vtable, which alters the binary format of the element. The alternative solution is embed a pointer to the items drop in the Vec along with the capacity and element length. I don't know Rust well enough to know if it can do that. Well, I'm sure it can with some helper macros but's that an admission the language doesn't support it well.

> For Vec, crABI is unlikely to give up much performance

Actually, the big speed gains from monomorphization come from small types. Consider Vec.get() for Vec<u32>. If get() doesn't know the length it's probably going to be implemented using memcpy(), but memcpy() is orders of magnitude slower than "mov %rax,nnn(%rbp,%rdx)". But if the u32 was a much bigger type the overhead imposed by implementing get() as a function that uses memcpy() rather than inline becomes tolerable.

That hints to the solution you see in C and C++: you need a mixture of monomorphization and shared libraries. C and C++ can do that with inline. For that to work you need separate .h, .c and .o (compiler output). Or perhaps the required information gets folded into the .o. In any case, the compiler gets two sorts of information from the library: the compiled code which can potentially be put in a dynamic library, and the parts the library author thinks need to be monomorphized like for speed, like Vec.get().

Rust has effectively dropped that separation. No one uses binary libraries because it's too hard . The result is everything is monomorphized. But is reality, in a large library the bits that need to be monomorphized for speed are a very small percentage of the code. Given most Rust code a typical Rust program uses comes from these large libraries (interestingly the kernel will be a notable exception), this blows up the complied time of most small programs enormously. It also thawrts the current Linux distributions practice of fixing security holes in libraries by just shipping a new version of the .so. Now they have to ship every program that depends on it. As I said, on my laptop that means every time libc.so has a bug, I'd have to reinstall over 2,000 programs.

I consider this a major wart in the language. But as I said, it likely won't effect the kernel.

Improved dynamic linking ABIs

Posted Feb 22, 2025 10:16 UTC (Sat) by farnz (subscriber, #17727) [Link] (49 responses)

Drop is fairly trivial to handle, since it's a function call to Vec's code for this particular instance of Vec<T>, and if you have the ability to handle function calls on Vec at all (including push, insert, get, indexing and pop, which also get affected by the type of T), you can handle drop that way, too. You fundamentally can't implement anything useful if your handling of something like Vec doesn't have different function behaviour for many functions, because of this.

But note that the current length, size of a pointer to an element (since Vec does not store elements directly, but rather a pointer to a contiguous list of elements), and capacity are all part of Vec itself, and right now in Rust, the memory layout of the 3 or 4 items that make up a Vec (capacity, length, pointer to contiguous array of T, optional pointer to additional data for T like T's vtable) is arbitrary for each instantiation of Vec in each compilation unit.

You appear to be aiming for something slightly different to the goals of crABI and other stable Rust ABI efforts; you're talking about removing monomorphization completely, so that the compile unit for Vec can output code for all of Vec's functions, and rely on runtime polymorphic behaviour to get the correct implementation, because that's what C++ does. Instead, though, the Rust stable ABI efforts (including crABI) try to come up with ways to guarantee that the visible behaviour of two separate instantiations of Vec::<T>::push have the same visible ABI, and thus it becomes possible to rely on just choosing one instantiation of each. Then, for functions that are externally polymorphic, you'd use the trick used by File::open today, to give yourself a tiny generic shim (correct by inspection) that calls into a much larger chunk of monomorphic code.

Improved dynamic linking ABIs

Posted Feb 22, 2025 18:30 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

> Then, for functions that are externally polymorphic, you'd use the trick used by File::open today, to give yourself a tiny generic shim (correct by inspection) that calls into a much larger chunk of monomorphic code.

In the C++ world, this is called PIMPL (pointer to implementation).

Improved dynamic linking ABIs

Posted Feb 23, 2025 1:47 UTC (Sun) by ras (subscriber, #33059) [Link] (47 responses)

> Drop is fairly trivial to handle, since it's a function call to Vec's code for this particular instance of Vec<T>

As understand it, Vec.drop() has to call the inner types drop(). There is only two ways it can know what to call. If you don't know at compile time the only option is put a function pointer to the drop() function somewhere. If all you have is traditional .so you're linking to, this is your only option. OO puts the pointer in the inner type. C++ does this via a vtable stored in each instance of the inner type. Alternatively you could store a point to T.drop() it in each Vec<T> instance, which you can do because the code that instantiated the Vec<T> object.

If you know the type of T compile time, monomorphization can create a special version of Drop<T> for Vec<T>. You need the source of Vec<T>.drop() to do that, but there are many ways of skinning that cat.

> you're talking about removing monomorphization completely,

No, I'm not. I'm saying there are various ways of doing it. Rust does it by recompiling everything, all the time, and as a consequence doesn't support pre-compiled libraries. That's an extreme. Both C and C++ allow programmer complete control over what is monomorphized, and what isn't.

Backtracking for a second, the requirement to avoid a function pointer is the compiler have access to the source for Vec<T>.drop(). That's all you need. Rust achieves that by giving the compiler access to the entire source for Vec and recompiles it every time for every Vec<T>, but as I said that's extreme. C and C++ achieve it by distributing two things: the compiled output (.a or .so), and the .h. The .h contains the source code for Vec<T>.drop() using inline, or templates or whatever. This is not "removing monomorphization completely". This is giving control of what is monomorphized and what is not to the programmer.

Rust effectively does not give you that choice, it monomorphizes all the time. That is the root cause it's compile time issues, and it's inability to support dynamic linking.

Improved dynamic linking ABIs

Posted Feb 23, 2025 12:55 UTC (Sun) by farnz (subscriber, #17727) [Link] (46 responses)

Rust allows, as far as I can tell, exactly the same level of control over what's monomorphized and what's not as C++ does. I can find no difference in how Clang treats std::vector to how Rust treats std::vec::Vec, complete with similar behaviour around how std::vector::~vector is treated as compared to std::vec::Vec::drop.

And once you start using C++20 modules, the distinction you're making between compiler output and types of compiler input goes away, too - the compiler does basically the same thing as Rust's compiler does.

Unlike C++, C does completely avoid this, by having no language-level support for generics. But if you use Rust without generics, you also don't get any monomorphization - monomorphization in Rust only takes place when you (a) have a type parameter, and (b) the code's behaviour changes when the type parameter's value changes. This is the same as C++, as far as I can see, bar the fact that C++ makes you do more manual work to use monomorphization correctly, so people are more likely to hand-write a buggy reimplementation of a generic than to share source.

Improved dynamic linking ABIs

Posted Feb 24, 2025 8:06 UTC (Mon) by ras (subscriber, #33059) [Link] (45 responses)

> But if you use Rust without generics, you also don't get any monomorphization - monomorphization in Rust only takes place when you (a) have a type parameter, and (b) the code's behaviour changes when the type parameter's value changes. This is the same as C++, as far as I can see

It is the same. What is not the same is C++ (and C) splits the source into .h and .cpp, when you compile against a cpp library you recompile the .h and link with the pre-compiled .cpp files. It's so simple everyone does it that way, and it yields the two benefits I mentioned - fast compile times, and the ability to fix a library by shipping a single shared library rather than all the binaries that depend on it.

In Rust, if doing that is possible it must be very hard, because one one does it that way.

Improved dynamic linking ABIs

Posted Feb 24, 2025 10:35 UTC (Mon) by farnz (subscriber, #17727) [Link] (42 responses)

C++ modules do not split the source like that, and there are many C++ projects (like Boost) which end up putting all the source in the .h file because it's the only way to guarantee that all use cases compile correctly. As a result, a lot of libraries in C++ land are in the same position as Rust, because the important parts of the code are in the .h file, and the precompiled object is tiny. Any bugfix requires a full rebuild of all dependents, as well as a new shared library file.

C is different precisely because it doesn't have compile-time generics, but instead requires cut-and-paste programming, with associated bugs where you notice an issue with (e.g.) StringVector, but don't fix it for your DoubleVector as well. If you do make use of the macro system to get generics, then you have the same problem.

And C++ build times aren't fast compared to Rust; that's not a benefit of the C++ model in my experience, where it's often slower than Rust at development builds (since Rust does a good job of incremental compilation, splitting the files into codegen units in ways a human wouldn't), and no faster at release builds (where LLVM's optimizer dominates in both cases).

Improved dynamic linking ABIs

Posted Feb 24, 2025 13:05 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (41 responses)

> C++ modules do not split the source like that

While they don't *require* that, any PIMPL-like mechanisms or desire to hide what modules are used to implement some functionality will still end up with splitting sources between interface and implementation. Because module interfaces need to be provided to consumers, any desire to keep things from them will require using separate implementation units. Compilers may be able to *help* with this by only updating BMI files as needed, but this will require behavior like ninja's `restat = 1` which (AFAIK) `make` completely lacks to not recompile consumers anyways.

Splitting implementation and interface in C++

Posted Feb 24, 2025 13:29 UTC (Mon) by farnz (subscriber, #17727) [Link] (40 responses)

I suspect that, in practice, people splitting sources and implementations will be rare in open source C++ modules; you have no reason to hide the implementation from consumers of the interface, since it's all open source, but it is extra work to separate them cleanly. You see similar in Rust, where things like Windows use Rust behind an ABI barrier (and only export the interface), but open source Rust projects tend not to bother.

Splitting implementation and interface in C++

Posted Feb 24, 2025 14:26 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Note that all modules used (transitively) need BMI-built in all consuming projects (e.g., if you use Boost and it uses, say, a modularized libarchive, your project needs BMIs for libarchive when importing the relevant Boost modules; consuming BMIs from an install tree is largely a dead end path due to how they work in practice), so it may be beneficial to completely hide module usage not otherwise needed in the interface.

Note that Windows is still only exposing a C ABI, so the fact that it is Rust, C, C++, or Fortran behind the scenes isn't really visible to consumers.

Splitting implementation and interface in C++

Posted Feb 24, 2025 17:03 UTC (Mon) by viro (subscriber, #7872) [Link] (38 responses)

Seriously? The only reason to split interface and implementation you is license considerations? Not, say it, keeping things feasible to reason about? The amount of code that needs to be reviewed for assessing validity of a change, perhaps? It does affect the complexity of analysis, and it's not even close to linear by size...

Splitting implementation and interface in C++

Posted Feb 24, 2025 17:06 UTC (Mon) by viro (subscriber, #7872) [Link]

grrr... s/implementation you/implementation for you/, sorry

Splitting implementation and interface in C++

Posted Feb 24, 2025 17:22 UTC (Mon) by farnz (subscriber, #17727) [Link] (3 responses)

Yes. The extra work of splitting something into an interface module and an implementation module is significant, and does not reduce the complexity of reasoning about a change, nor the amount of code that has to be reviewed for assessing validity of a change.

This is distinct from splitting the implementation up inside a single C++ module; having multiple module units, one for the exported interface and many for the internal implementation, makes a lot of sense, but having two separate C++ modules, one of which exports an unimplemented interface, and the other of which exports an implementation of that interface, is a mess, since it means I have to make sure that the two separate modules are kept in sync manually.

Why create that extra workload when I can have a single module with an internal module partition such that it's very obvious when I change the interface without changing the implementation to match, and where I have one thing to release instead of two?

Splitting implementation and interface in C++

Posted Feb 25, 2025 0:00 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (2 responses)

> Why create that extra workload when I can have a single module with an internal module partition such that it's very obvious when I change the interface without changing the implementation to match, and where I have one thing to release instead of two?

If the partition is imported into the interface for any reason, it must be shipped as well.

Splitting implementation and interface in C++

Posted Feb 25, 2025 10:01 UTC (Tue) by farnz (subscriber, #17727) [Link] (1 responses)

Sure, but I'm shipping full source anyway, and I can check for people exporting parts of the internal partition in CI, just as I'd have to have similar checks in place to stop people moving code from the interface module to the implementation module.

Remember that the goal here is one module, nicely structured for ease of maintenance, and thus split across multiple module units, with an internal module partition to make the stuff that's for internal use only invisible from outside the module, rather than multiple modules.

Splitting implementation and interface in C++

Posted Feb 25, 2025 11:57 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

FWIW, CMake does this by enforcing that `PRIVATE TYPE CXX_MODULES` files are never imported from `PUBLIC TYPE CXX_MODULES` sources, so at least it can help enforce the "don't expose private bits in public interface units" part.

Splitting implementation and interface in C++

Posted Feb 24, 2025 17:24 UTC (Mon) by Wol (subscriber, #4433) [Link]

> Seriously? The only reason to split interface and implementation you is license considerations?

That's not what he said. He said "extra work". Which in reality usually means "push the work down the road until I get to it". Which also often in reality means "I'll never get to it".

It wouldn't get done in commercial circles either, if secrecy didn't have a (at least nominal) value.

Time pressure usually turns out to be an extremely important consideration.

Cheers,
Wol

Splitting implementation and interface in C++

Posted Feb 24, 2025 17:32 UTC (Mon) by mb (subscriber, #50428) [Link] (27 responses)

>The amount of code that needs to be reviewed for assessing validity of a change, perhaps?

All Rust installs ship a tool that extracts the public interface of your crate and puts it into a nice html document for review:
cargo doc

This is much better than manually typing in the redundant code for the public interface declarations.
It's easy to navigate and includes all details of your public interfaces.

Splitting implementation and interface in C++

Posted Feb 25, 2025 1:27 UTC (Tue) by ras (subscriber, #33059) [Link] (26 responses)

> All Rust installs ship a tool that extracts the public interface of your crate and puts it into a nice html document for review:
cargo doc

I had said earlier I wanted the ability to say to the compiler "not here, at this boundary conventional linker is all you need". I also said C++ gives you the ability to do that, by splitting stuff into .h and .cpp. @franz said "but that's the old way, boost for example doesn't do that". That's true, but the point is the people who wrote boost made the decision to adopt the way Rust does it. C++'s std makes a different decision. @taladar said C++ compiles are slow. I'm guessing that's because the packages / libraries he is working adopt this newfangled way, and everything gets recompiled all the time. He's blaming C++ for that, but I'd argue that fault lies at least as much with the package authors for making that choice.

@franz then said "oh but it's hard to think about what has to be monomorphized and what isn't, and besides redeclaring everything in .h is verbose and a lot of work". I don't have much sympathy for the first part - I did it all the time when I wrote C++. The second is true, the information in .h is redundant. A modern language shouldn't make you type the same thing twice without good reason.

Those language differences were swirling around in my head when I wrote: "Or perhaps the required information gets folded into the .o". It was a thought bubble. But it's key point illustrated the idea nicely with your "cargo doc" comment. Rust could add something to the language that says "this source is to be exported (made available) to people who want to link against my pre-compiled library", in the same way "cargo doc" exports stuff. That information would be roughly equivalent to what's put in a .h file now. But where would you put it? The thought bubble was place it a section of the .elf object that holds the compiled code. Call it say a ".h" section. Then when someone wants to compile against your library, they give that .o / .so / .a to both the compile phase (which looks for the equivalent of the .h sections) and the link phase (which just wants the compiled code for the non-monomorphized stuff, which - if the programmer has done their job - should be the bulk of it).

The ultimate goal is to allow the programmer to decide what needs to be monomorphized, and what can be pre-compiled. And to have Rust tell the programmer when they've mucked that boundary up. I guess it would get an error message like: "This type / function / macro has to be exported to the .h, because it depends on type T the caller is passing in". Right now Rust programmers don't have that option, and that leads to the trade-offs I mentioned.

Splitting implementation and interface in C++

Posted Feb 25, 2025 3:50 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (24 responses)

One big problem with this approach is versioning. It's less of a problem for internal libraries in monolithic projects like systemd or uutils, but it will become a problem if the package is exposed via system-level package managers. And if you're in a monolithic project, then there's no need to embed the pre-instantiated type information into .so files, you can just store it in an ".h" file.

Splitting implementation and interface in C++

Posted Feb 25, 2025 8:06 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

Hmm ... pile of musings here ...

But if you had stuff that was specifically meant to be a library, why can't you declare "I want to monomorphise these Vec<T>s". Any others are assumed to be internal and might generate a warning to that effect, but they're not exported.

And then you add rules about how the external interface is laid out, so any Rust compiler is guaranteed to create the same export interface. Again, if the programmer wants to lay it out differently, easy enough, they can declare an over-ride.

And then lastly, the .o or whatever the Rust equivalent is, contains these declarations to enable a compiler of another program to pull them in and create the correct linkings.

Okay, it's more work having to declare your interface, but I guess you could pull the same soname tricks as C - extending your interface and exports is okay, but changing it triggers a soname bump.

Cheers,
Wol

Splitting implementation and interface in C++

Posted Feb 25, 2025 10:43 UTC (Tue) by farnz (subscriber, #17727) [Link]

When you provide T, it's monomorphized for you. The hard case is when I want to provide Foo<T>, and allow you to provide an arbitrary T that I haven't thought about up-front.

There are, currently, two reasons for Rust to not have a stable ABI, both being worked on by experts in the field (often overlapping with people solving this problem for Swift and for C++ modules:

Rust explicitly allows the memory layout of most data structures to vary between compilations, which lets it do things like completely elide fields that never change at runtime, along with all the code to modify them. This is obviously not compatible with a stable ABI for that structure.
The generics problem. This is a generally hard problem, and no-one has a great solution; there are tricks that reduce the scale of the problem (which are also needed for static linking, because of the compile time and binary size issues), and Rust has had a working group looking into how many of the tricks can be machine-applied to naïve code, as opposed to requiring a human to split the code into generic and monomorphic parts.

There is, however, serious work going into a #[export] style of ABI marker that allows you to mark the bits (or an entire crate) as intended to have a stable ABI, and errors if the compiler can't support that. This will, inevitably, be a restricted subset of the full capabilities of Rust (since macros, generics, and other forms of compile-time code creation can't be supported in an exported ABI), but it's being actively thought about as a research project with a goal of allowing as much code as possible to be dynamically linked while not sacrificing any of the safety promises that Rust makes today using static linking.

Splitting implementation and interface in C++

Posted Feb 25, 2025 21:29 UTC (Tue) by ras (subscriber, #33059) [Link] (21 responses)

> One big problem with this approach is versioning.

I don't get the problem. libc.so.X.Y already handles versioning pretty well.

Putting the .h's in the .elf does solve one problem that bites me on occasion - the .h's don't match the .so I'm linking against. It would be nice to see that nit disappear.

Splitting implementation and interface in C++

Posted Feb 26, 2025 9:19 UTC (Wed) by taladar (subscriber, #68407) [Link] (13 responses)

That might help if you have the updated .so at compile time but is completely useless if you switch to a new .so for an already compiled application or other library using the updated one.

Splitting implementation and interface in C++

Posted Feb 26, 2025 11:36 UTC (Wed) by ras (subscriber, #33059) [Link] (12 responses)

> but is completely useless if you switch to a new .so for an already compiled application

I expect it would be the same story as C or C++. It has the same traps - don't expect an inline function (or template in C++'s case) in a .h to be effected by distributing a new .so. Despite that limitation shipping updated .so's to fix security problems happens all the time. The rule is always new stuff can be added, but existing stuff can't be changed. It would be the same deal with Rust, but would cover the ".h" section too, meaning you can add new exported types of monomorphized functions, but not changed existing ones.

Putting the .h section in the .so brings one advantage. There is no way for a C program to know if the .h it is compiled against matches the one the .so was compiled against. But a Rust program compiled against a .so could check the types in the .h section match the ones it was compiled with, and reject it if they aren't.

Splitting implementation and interface in C++

Posted Feb 26, 2025 12:26 UTC (Wed) by farnz (subscriber, #17727) [Link] (11 responses)

The problem is that shipping an updated .so in the way C or C++ do it runs the risk of invoking UB from the "safe" subset of Rust, and one of Rust's promises is that invoking UB requires you to use "unsafe Rust". Thus, just copying the C way of doing things isn't acceptable, because it can take a safe program and cause it to invoke UB.

For example, if you go deep into how Vec::shrink_to_fit is implemented internally, you find that you have a set of tiny inline functions that guarantee that an operation is safe that leads down to a monomorphic unsafe shrink_unchecked function that actually does the shrinking.

Because these are all shipped together, it's OK to rearrange where the various checks live; it would be acceptable to move a check out of shrink_unchecked into its callers, for example. But, in the example you describe, you've separated the callers (which are inlined into your binary) from the main body of code (in the shared object), and now we have a problem with updating the shared object; if you move a check from the main body into the callers, you now must know somehow that the callers are out-of-date and need recompiling before you can update the shared object safely.

C and C++ implementations handle this by saying that you must just know that your change (and a security fix is a change to existing stuff, breaking your rule that "new stuff can be added, but existing stuff can't be changed") is one that needs a recompile of dependents, and it's on you to get this right else you face UB for your mistakes. Rust is trying to build a world where you only face UB if you explicitly indicate to the compiler that you know that UB's a risk here, not one where a "trivial" cp new/libfoo.so.1 /usr/lib/libfoo.so.1 can create UB.

Splitting implementation and interface in C++

Posted Feb 26, 2025 13:13 UTC (Wed) by Wol (subscriber, #4433) [Link] (10 responses)

> Because these are all shipped together, it's OK to rearrange where the various checks live;

But if you've explicitly declared an interface, surely that means rearranging the checks across the interface is unsafe in and of itself, so the compiler won't do it ...

Cheers,
Wol

Rearranging across the interface

Posted Feb 26, 2025 14:15 UTC (Wed) by farnz (subscriber, #17727) [Link] (9 responses)

That's why I chose that particular example; the explicitly declared interface is:


#[inline]
impl<T, A: Allocator> Vec<T, A> {
    pub fn shrink_to_fit(&mut self);
}

The compiler could stop you changing shrink_to_fit quite easily, because it's an external interface, but it uses a RawVec<T, A> as an implementation detail, which uses a heavily unsafe RawVecInner<A> as a monomorphic implementation detail. The current implementation of Vec::shrink_to_fit checks to see if the length of greater than the capacity, and if it is, calls the inline function RawVec::shrink_to_fit(self.buf, length). In turn, RawVec::shrink_to_fit simply calls the inline function RawVecInner::shrink_to_fit(self.inner, cap, T::LAYOUT) (which is a manual monomorphization so that RawVecInner is only generic over the allocator chosen, not the type in the vector). Following that, RawVecInner::shrink_to_fit arranges to panic if it can't shrink, and calls the inline function RawVecInner::shrink(&mut self, cap, layout). This then panics if you're trying to grow via a call to shrink, then calls the unsafe function RawVecInner::shrink_unchecked.

There's a lot of layers of inline function here, each doing one thing well and calling the next layer. But it would not be unreasonable to change things so that RawVecInner::shrink_unchecked does the capacity check that's currently in RawVecInner::shrink, and then have a later release move the capacity check back to RawVecInner::shrink; the reason they're split the way they are today is that LLVM's optimizer is capable of collapsing all of the checks in the inline functions into a single check-and-branch, but not of optimizing RawVecInner::shrink_unchecked on the assumption that the check will pass, and doing all of this means that LLVM correctly optimizes all the inline functions down to a single check-and-branch-to-cold-path, followed by the happy path code if all checks pass.

And note that the reason that this is split into so many tiny inline functions is that there's other callers in Vec that call different sequences of inline functions - rather than duplicate checks, they've been split into other functions so that you can call at the "right" point after your function-specific checks.

But, going back to the "compiler shouldn't do it"; why should it know that moving a check in one direction inside RawVecInner (which is an implementation detail) is not OK, but moving it in the other direction is OK? For this particular call chain, only RawVecInner::shrink_unchecked is going to be in the shared object, because the remaining layers (which are critical to the safety of this specific operation) are inlined.

Rearranging across the interface

Posted Feb 26, 2025 15:45 UTC (Wed) by Wol (subscriber, #4433) [Link] (8 responses)

So what you're saying is, if you the programmer move the checks across the interface boundary, the compiler has no way of knowing you've done it?

Hmmm ...

That is an edge case, but equally, you do want the compiler to catch it, and I can see why it wouldn't ... but if you're building a library I find it hard to see why you the programmer would want to do it - surely you'd either have both sides of the interface in a single crate, or you're explicitly moving stuff between a library and an application ... not good ...

Cheers,
Wol

Rearranging across the interface

Posted Feb 26, 2025 16:32 UTC (Wed) by farnz (subscriber, #17727) [Link] (4 responses)

No; I'm saying that if the compiler doesn't even know that this is an interface boundary, why would it bother detecting that you've moved code across the boundary in a fashion that's safe when statically linked, but not when dynamically linked?

Put concretely, in the private module raw_vec.rs (none of which is exposed as an interface boundary), I move a check from shrink_unchecked to shrink; how is the compiler supposed to know that this is not a safe movement to make, given that shrink is the only caller of shrink_unchecked? Further, how it is supposed to know that moving a check from shrink to shrink_unchecked is safe? And, just to make it lovely and hard, how is it supposed to distinguish "this check is safe to move freely" from "this check must not move"?

And note that "checks" and "security fixes" look exactly the same to the compiler; some code has changed. How is the compiler supposed to distinguish a "good" change from a "bad" change?

Rearranging across the interface

Posted Feb 26, 2025 21:43 UTC (Wed) by Wol (subscriber, #4433) [Link] (3 responses)

> No; I'm saying that if the compiler doesn't even know that this is an interface boundary, why would it bother detecting that you've moved code across the boundary in a fashion that's safe when statically linked, but not when dynamically linked?

Because if the whole aim of this is to create a dynamic library, the compiler NEEDS to know this is an interface boundary, no?

Cheers,
Wol

Rearranging across the interface

Posted Feb 27, 2025 10:44 UTC (Thu) by farnz (subscriber, #17727) [Link] (2 responses)

But then you're getting into a mess around defining what is, and is not, a safe code change inside the ABI boundary. If you do make the internals of a crate (not the exported interface) the ABI boundary, you're now in a position where the compiler has to make a judgement call - "is this change inside the internals of a library a bad change, or a good change?".

Note that when making this judgement call, it can't just look at things like "is this moving a check across an internal boundary", since some moves across an internal boundary are safe, nor can you condition it on removing a check from inside the boundary (since I may remove an internal check that is guaranteed to be true since all the inline functions that can call this have always done an equivalent check, and I'm no longer expecting more inline functions without the check).

Rearranging across the interface

Posted Feb 27, 2025 14:07 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

but if the crate IS the compilation object (as it would be if it's a library, no?) then surely the external boundary is the external declaration - what the library provides to all and sundry - then there's no problem with any internal moves?

If an external application cannot see the boundary, then it's not a boundary! So you'd need to include the definition of all the Ts in Vec<T> you wanted to export, but the idea is that the crate presents a frozen interface to the outside world, and what goes on inside the crate is none of the caller's business. So internal boundaries aren't boundaries.

Cheers,
Wol

Rearranging across the interface

Posted Feb 27, 2025 14:12 UTC (Thu) by farnz (subscriber, #17727) [Link]

No, for performance reasons. We inline parts of our libraries (even in C, where the inlined parts go in the .h file) into their callers because the result of doing so is a massive performance boost from the optimizer - which can do things like reason "hey, len can't be zero here, so I can eliminate the code that handles the empty list case completely".

To get the sort of boundary you're describing, we do static linking and carefully hand-crafted interfaces for plugins. That's the state of play today, for everything from assembly through C to Agda and Idrs; the goal, however, is to dynamically link, which means that we need to go deeper. And then we have a problem, because the moment you go deeper, your boundaries stop applying, thanks to inlining.

Rearranging across the interface

Posted Feb 26, 2025 18:04 UTC (Wed) by excors (subscriber, #95769) [Link] (2 responses)

As I understand it, the issue is that "interface boundary" can mean either "API boundary" or "ABI boundary". `Vec<T, A>::shrink_to_fit` is an API boundary; it's publicly documented and safe and has stability guarantees. But in a hypothetical Rust ABI, that API couldn't be an ABI boundary, because it depends on generic type parameters that aren't known when the .so is compiled.

`RawVecInner<A>::shrink_to_fit` could be an ABI boundary, because that doesn't depend on `T` (and we'll ignore `A`), but it's currently not an API boundary. It can't be made into a public API because its safety depends on non-trivial preconditions (like being told the correct alignment of `T`) and that'd be terrible API design - preconditions should be as tightly scoped as possible, within a function or module or crate. So you'd have to invent a new category of interface boundary, which is both an internal API and an ABI, with stability guarantees (including for the non-machine-checkable safety preconditions) and with tooling to help you fulfil those guarantees, which sounds really hard.

Rearranging across the interface

Posted Feb 26, 2025 22:46 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

> So you'd have to invent a new category of interface boundary, which is both an internal API and an ABI, with stability guarantees (including for the non-machine-checkable safety preconditions) and with tooling to help you fulfil those guarantees, which sounds really hard.

Like putting the equivalent of a C .h in the crate?

But I would have thought if the compiler can prove the preconditions as part of a monolithic compilation, surely it must be able to encode them in some sort of .h interface in a library crate?

Of course, if you get two libraries calling each other, then the compiler might have to inject glue code to rearrange the structures passed bwtween the two :-)

Cheers,
Wol

Rearranging across the interface

Posted Feb 27, 2025 12:43 UTC (Thu) by farnz (subscriber, #17727) [Link]

The compiler doesn't prove anything for the danger cases; it relies on the human assertion that they've checked that this unsafe block is safe, given the code that they can see today.

The challenge is that we're talking about separating the unsafe block (in an inline function) from the unsafe fn it calls (in the shared object); this means that the human not only has to consider the unsafe code as it stands today, but all possible future and past variants on the unsafe code, otherwise Rust's safety promise is not upheld.

That's clearly an intractable problem; the question is about reducing it down to a tractable problem. There's three basic routes to make it tractable:

Ignore the problem, and rely on the humans being infallible and remembering to change a "version identifier" when making a change to both the unsafe fn and its inlined callers. This makes it far too likely that you'll breach Rust's safety promises for Rust to adopt this.
Ensure that there's an ABI change whenever anything in the body of the unsafe fn changes. This is problematic, because security fixes are likely to change the body, and those are the cases where you most want to be able to swap in a new shared object.
Build a reverse tree of inline functions in this library that call the unsafe fn, and ensure that if any of them changes, the unsafe fn's ABI changes. This means that you can change the unsafe fn freely as needed for a security fix, but if you change any inlined caller, or add a new inlined caller, you change the ABI of the unsafe fn and require a new shared object, even if this change was harmless.

There's room to be sophisticated with symbol versioning in all cases; for example, you can have a human assert that this version of the unsafe fn is compatible with the inlined callers from older versions (thus allowing a swap of a shared object), or in case 3 you can use it to allow new inlined callers to use a new shared object, while allowing the existing ones to use either old or new shared objects.

In all cases, though, the trouble is preventing the human proofs of correctness being invalidated by creating new combinations of inline functions and out-of-line unsafe code that weren't present in any source version; you want the combinations to be ones that a human has approved.

Versioning of shared objects

Posted Feb 26, 2025 10:53 UTC (Wed) by farnz (subscriber, #17727) [Link]

Note that libc handles versioning well because the glibc maintainers do a lot of hard and non-trivial work to have things like compatibility symbols so that you can swap to a later glibc without breakage. You can do a similar level of work in Rust today to get dynamic linking working, and working well.

What C has that Rust doesn't is that it's fairly trivial to take a C library, build it into a .so, and have it work as long as upstream doesn't make a silently breaking change (which can result in UB, rather than a failure); it's also fairly simple to patch the build system so that the .so is versioned downstream of the library authors, so that they are ignorant of the use as a shared library. This is being worked on for Rust, but the goal in Rust is to ensure that any breaking changes upstream result in a failure to dynamically link, rather than a risk of UB.

Splitting implementation and interface in C++

Posted Feb 26, 2025 21:14 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

There are several issues. Rust is very happy to use slightly different versions of libraries, if your dependencies are locked at a different time.

This is fine for static linking, but you don't generally want to end up with 15 versions of the same shared library with a slightly different patch version. So you ideally should be able to control the versions so that distro-provided libraries are used as much as possible, overriding Cargo's resolution mechanism. Ideally, making sure that you get CVE fixes.

Doing it properly is not trivial.

Splitting implementation and interface in C++

Posted Feb 26, 2025 21:19 UTC (Wed) by mb (subscriber, #50428) [Link] (4 responses)

>if your dependencies are locked at a different time.

Dependency locks are ignored.
Only the top level application crate lock matters.

>slightly different versions of libraries

No. It can include several *incompatible* versions of the libraries with a different major semantic version.

Splitting implementation and interface in C++

Posted Feb 26, 2025 21:25 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

> Only the top level application crate lock matters.

Yes, that's what I mean. One app can lock somelibrary#1.1.123, and another one at somelibrary#1.1.124 If this is packaged naïvely, you'll end up with two shared objects for `somelibrary`.

Splitting implementation and interface in C++

Posted Feb 27, 2025 5:27 UTC (Thu) by mb (subscriber, #50428) [Link] (2 responses)

It's fully up to the builder/distributor what to do with application level locks.
(I almost never use them and I almost always provide them.)

As 1.1.124 and 1.1.123 are semantically compatible versions you can just upgrade all packages to 1.1.124. And it's also likely that it would work with 1.1.123, too.

This is really not different at all from C library dependencies with backward compatible versions.
Except that typical C applications simply don't provide a lock information, so you're fully on your own.
Providing lock information is better than providing no lock information.

Splitting implementation and interface in C++

Posted Feb 27, 2025 18:41 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

I checked a few Rust applications, and most of them do have lockfiles. So something will need to be done with that. I dislike just ignoring them, but then perhaps some form of a limited override should be OK?

And yep, it's strictly better than C. It's just not a trivial task...

Splitting implementation and interface in C++

Posted Feb 27, 2025 19:11 UTC (Thu) by mb (subscriber, #50428) [Link]

The default for cargo install is to ignore the lock file:
https://doc.rust-lang.org/cargo/commands/cargo-install.ht...

There's no need to use a lock file or to use an online crates forge.
You can just use what is --offline available in your distribution.

I don't really get it why this would be a nontrivial task.

>I dislike just ignoring the

Well, you can either use it or ignore it.
If you don't want to use it, because you want to use your own packaged dependencies there's only the option to ignore it, right?

Splitting implementation and interface in C++

Posted Feb 25, 2025 6:48 UTC (Tue) by mb (subscriber, #50428) [Link]

> That information would be roughly equivalent to what's put in a .h file now. But where would you put it?

Put it into a my-public-interface crate and generate the docs for it? I don't see the problem.

Splitting implementation and interface in C++

Posted Feb 24, 2025 17:39 UTC (Mon) by farnz (subscriber, #17727) [Link] (3 responses)

To express it slightly differently, why is the Linux kernel a single module with multiple internal partitions, rather than separate modules for the VFS interface, MM interface, network interface etc, along with implementation modules that implement each of those interfaces? If the benefits are as big as you're claiming, surely it would make sense to separate out the interfaces and implementations into separate modules, rather than just have separate partitions internally?

Splitting implementation and interface in C++

Posted Feb 25, 2025 11:16 UTC (Tue) by taladar (subscriber, #68407) [Link] (2 responses)

Whenever a project is a large single library or repository the answer is usually "because the tooling makes it painful to split it up", not "there is a good reason to have a humongous pile of code".

Splitting implementation and interface in C++

Posted Feb 25, 2025 11:24 UTC (Tue) by farnz (subscriber, #17727) [Link]

Note, though, that once you have tooling that makes splitting it up easy, the dividing line is rarely as simple as "interfaces" and "implementations". You're more likely to have splits like "VFS interface and implementation", "ext4 interface and implementation" etc.

Splitting implementation and interface in C++

Posted Feb 25, 2025 21:51 UTC (Tue) by ras (subscriber, #33059) [Link]

> the answer is usually "because the tooling makes it painful to split it up",

Or "it's faster because we can optimise".

My favourite counter example to this is LVM / DM vs ZFS, possibly because I'm a recent user of ZFS. LVM / DM / traditional file system give you similar a outcome to ZFS, albeit with a more clunky interface because "some assembly is required". The zfs CLI is nice. However by every other metric I can think of LVM / DM / ... stack wins. The stack is faster, the modular code is much easier to understand, they have less bugs (I'm tempted to far less), and you have more ways of doing the same thing.

This is surprising to me. I would have predicted to the monolithic style to win on speed at least, and are easier to extend (which evidence against "it's easier to develop that way").

I guess there is a size when the code base becomes too much for one person. At that point it should become modular, with each module maintained by different people sporting an interface that requires screaming and yelling to change. But by that time it's already a ball of mud, I guess the tooling is a convenient thing to blame for not doing the work required to split it up.

Improved dynamic linking ABIs

Posted Feb 24, 2025 11:27 UTC (Mon) by taladar (subscriber, #68407) [Link]

As a past C++ programmer, current Rust programmer and current Gentoo user I would like to just call the idea that C++ compile times are anything that could be described as "fast" utter nonsense.

Improved dynamic linking ABIs

Posted Feb 24, 2025 11:55 UTC (Mon) by excors (subscriber, #95769) [Link]

> What is not the same is C++ (and C) splits the source into .h and .cpp, when you compile against a cpp library you recompile the .h and link with the pre-compiled .cpp files. It's so simple everyone does it that way

Not everyone - even disregarding the cases where templates force you to put all your code in the .h file, there are plenty of libraries that choose to put all their code in the .h file so users don't have to fight with C/C++ build systems or package managers. You just download the code and #include it and it works.

E.g. https://github.com/nothings/stb explains "The idea behind single-header file libraries is that they're easy to distribute and deploy because all the code is contained in a single file" and "[these libraries] are only better [than other open source libraries] in that they're easier to integrate, easier to use, and easier to release", and it's pretty popular as a result of that. There's a big list of header-only libraries at https://github.com/p-ranav/awesome-hpp . It's a good way to make your library more attractive to developers, because package management in the C/C++ world is so bad.