japaric
commented
4 years ago We had problems with this in cortex-m-rt when the number of default codegen units changed from 1 to ncpus. With codegen-units = 1 each crate compiles down to a single object file. with more codegen units a crate can be compiled to many object files (all packed in the same archive -- .rlib is just a .a file with .o files in it). The linker processes each linker argument in order; when it sees an rlib it walks over each object file in the rlib one at a time. The linker can stop walking an rlib "midway" (it stops when all "undefined" symbols are resolved) so all the object files that make up a single crate may not be inspected by the linker. Note that not all linker implementations are this "lazy", some may inspect all objects files in an archive and be lazy at the linker argument level -- GNU LD and LLD may be using different strategies here.
When I comment this line out, the output still seems to have all of its content.
The crate in the nomicon is pretty small; it's unlikely that the compiler will split it in 2 or more object files. Also even when splitting happens you may not always observe the issue because how symbols get mapped to object files can change with each compiler release (how these are ordered in the .rlib matters) . You need a big rt crate and bad luck to run into this problem.
skoe
Thank for the great documentation!
I have a question about EXTERN, which is described in https://docs.rust-embedded.org/embedonomicon/memory-layout.html#extern
When I comment this line out, the output still seems to have all of its content. I also tried it with
cargo cleanand with--release. As I like to understand everything, can you explain or show an example where it is actually needed?