How do .rlibs work? Do those resemble these .sbos? .rlibs look like archives IIRC but maybe they're able to resolve relocations internal to them?
EDIT: after some brief searching around, I believe .rlibs are little more than archives with rust-specific metadata and internal relocations are not resolved.
There is nothing magical in resolving the local relocations. It is just that current static libraries (static archives of plain .o files) are produced directly using "ar" and don't even go through the linker... The changes to the linker so to apply the relocation finalization are less than 50 lines of code on top of the existing "ld -r" that creates a relocatable object (which despite its name, does not handle relocations).
The key point in the proposal for a static-bundle-object is to properly handle static libraries as linked objects, instead of as a bunch of plain .o files.
Regarding --whole-archive, is it correct that it would be the default and you could opt-out of it with the function-sections/gc-sections combination?
Are there cases in which function-sections doesn't work (GCs too much) but a hypothetical "file-sections" does? For example cases in which the code relies on side effects of global constructors, but those would be left out by function-sections?
> Regarding --whole-archive, is it correct that it would be the default and you could opt-out of it with the function-sections/gc-sections combination?
This is the current intention, as implemented in the up-to-date draft: https://github.com/bminor/binutils-gdb/commit/99aef6ba8db670.... Please note however that one would no longer need to specify the "--whole-archive" flag, hence resolving issues with potential duplicate placement of the static library in the linker's CLI.
> Are there cases in which function-sections doesn't work (GCs too much) but a hypothetical "file-sections" does? For example cases in which the code relies on side effects of global constructors, but those would be left out by function-sections?
Good question. In the first article in this series I discussed issues with global constructors and was pretty much waved away, being told that code should not be written this way. One of the members of the ELF committee did suggest an alternative for handling it yet pretty much mentioned that there are still missing pieces that require handling for their proposal to work (https://groups.google.com/g/generic-abi/c/sT25-xfX9yc/m/NRo0...).
Would you consider adding something like "file-sections" support to -r, preserving file boundaries as separate subsections? I have no idea how hard it would be.
Correct me if i'm wrong, but wouldn't "file-sections" be identical to generating a static bundle object per original object file, and wrapping them all inside a .a archive?
OK, now I understood the gap. There is a technical limitation for relocation resolution when the relocation is against a different section. This means that for function sections we de-facto have no relocation finalization, only conversion of symbols from "global" to "local".
Hence, for a "file-sections" flag, we would only resolve relocations within a given file, but will leave intact relocations that cross the file boundary. Accordingly, this means that "function-sections" is identical to generating a static bundle object per original object file, and bundling them all together inside a .a archive.
> Accordingly, this means that "function-sections" is identical to generating a static bundle object per original object file, and bundling them all together inside a .a archive.
Ah, how are local symbols resolved within the whole .a file? I thought it would be only within the individual object file.
EDIT: after some brief searching around, I believe .rlibs are little more than archives with rust-specific metadata and internal relocations are not resolved.