Add chapter on libs and metadata. #1044
Conversation
|
BTW, I had no idea where to stick this in the SUMMARY hierarchy. I think "backend" makes sense, but I'm uncertain (because metadata is used almost everywhere). |
|
I've wanted to see info about metadata and rustlibs in the dev-guide for a |
| @@ -145,6 +145,7 @@ | |||
| - [Debugging LLVM](./backend/debugging.md) | |||
| - [Backend Agnostic Codegen](./backend/backend-agnostic.md) | |||
| - [Implicit Caller Location](./backend/implicit-caller-location.md) | |||
| - [Libraries and Metadata](./backend/libs-and-metadata.md) | |||
There was a problem hiding this comment.
Perhaps instead put this under "High-level compiler architecture"? That's where queries and serialization are discussed, which are somewhat related.
| * Object code, which is the result of code generation. This is used during | ||
| regular linking. There is a separate `.o` file for each [codegen unit]. The | ||
| codegen step can be skipped with the [`-C | ||
| linker-plugin-lto`][linker-plugin-lto] CLI option, which means each `.o` |
There was a problem hiding this comment.
Why does rustc reuse .o as the extension for bitcode files? I would expect .ll or something.
There was a problem hiding this comment.
What do you mean? My understanding is this is talking about object code (not LLVM bitcode), so .o is correct.
There was a problem hiding this comment.
See the line below, this is reused for bitcode too: https://github.com/rust-lang/rustc-dev-guide/pull/1044/files#diff-3a3e84f49881b6db90d4538e80369c04098f7a6fe6d20cca0ccad9e46fead011R24
There was a problem hiding this comment.
Ah, it confused me that your comment only extended until the line before :)
There was a problem hiding this comment.
In the past, the bitcode was stored as a separate, compressed file in the archive (with the .bc.z extension). This was changed to simplify the implementation and to match the behavior of clang, which always places the bitcode in the .o file.
| loader will skip any crates that have the wrong SVH. | ||
|
|
||
| The SVH is also used for the [incremental compilation] session filename, | ||
| though that usage is mostly historic. |
There was a problem hiding this comment.
What's used instead? I'm not sure what you mean by historic here.
There was a problem hiding this comment.
In the past, rustc would use the incremental directories of dependencies for resolving queries, and would use the SVH in the directory name to ensure it was querying the correct dependency. That was removed (it no longer looks for dependencies), and AFAIK it no longer looks at the SVH in the filename. I think it could be replaced with a random number and have the same effect (it uses a random number before it knows the svh, it gets renamed at the end).
The incremental naming convention is described at https://doc.rust-lang.org/nightly/nightly-rustc/rustc_incremental/persist/fs/index.html.
This adds a new chapter on library files and metadata, and how these things interact.
This leans a bit heavy from a Cargo/build-tools perspective, but I think this information is useful. I think it is difficult to hit a good balance of too-much or too-little detail, since things tend to change a lot over time. Not sure if I hit the mark there.
I think this is pretty accurate, but I am not involved with compiler development a lot, so there may be some things that are incomplete or wrong.
Closes #468 (I think?)