For those not familiar, Source Server/Source Indexing is a specification in the PDB symbols file, which provides a way to query a URL for file sources not found on the local drive.
This lets you:
Step through code built on a different machine.
See code locations from crash dumps without any extra information.
More easily debug very old versions (for which your local source is out of date).
Step through the standard library without additional downloads or mappings.
Rust makes it fairly easy to add this to our PDBs, as the standard library is already hosted publicly. See this link for how it can be configured for Github. for more information.
I'm interested in adding support for Source Server / Source Indexing to rustc for the standard library, and potentially as an option for other public libraries (perhaps through a Cargo.toml config), down the road.
I've never contributed to rustc before -- does anyone have any pointers on where I should look, or who I should talk to?
Right, for context, Windows stores symbols in separate PDB files, not within the binary itself.
Right now, you can debug into the standard library using those symbols, but you can't see any code unless you have the correct version of the standard library installed, and you set up a custom mapping.
Here's another great introduction to Source Indexing (aka Source Server):
The standard library and other libraries are rarely dynamically linked to rust executables. Pdb files are only generated for executables and dynamic libraries. A pdb for std-*.dll doesn't apply to executables statically linking the standard library. In addition libraries from crates.io are locally compiled from scratch. Only the .pdb files created locally have any chance of being correct. Using a different rustc versions or even flipping a feature flag would produce produce object files that are incompatible with the debuginfo.
If you want to use source server, you will have to upload the .pdb files generated for your executable yourself.
To be clear, I'm not asking about Symbol Server, which downloads pdbs for debugging. I agree that wouldn't be functional for the reasons you mentioned.
I'm talking about Source Server. This is a different tool that makes the existing statically-linked pdb's more powerful.
For example, if I compile a binary I get:
main.exe
main.pdb
main.pdb contains all of the symbols for the std and my binary, but the symbols for the std only contain paths to the build server. (ie. /rustc/c09a9529c51cde41c1101e56049d418edb07bf71\/library\std\src\sys\windows\thread_local_key.rs)
Adding Source Server support means that the debugger would know to pull from
https://github.com/rust-lang/rust/blob/c09a9529c51cde41c1101e56049d418edb07bf71/library/std/src/sys/windows/thread_local_dtor.rs
Since this can just link to the sources on GitHub and doesn't require any new infrastructure, I don't think this necessarily needs an RFC. I think it would suffice to post a PR with a prototype, and then relevant teams may need to sign off on that with an FCP.
I would suggest a few steps here:
Add an unstable option to rustc, to add Source Server information to a PDB. For instance, -Z pdb-source-server=URL. This PR should include a test to verify that the option works. You don't need an RFC for this, and since it's an unstable option and thus easily reversible, it doesn't necessarily need a compiler team FCP (though the compiler team may choose to do so anyway).
Modify the rustc build system to support feeding in a value for that unstable option when doing a build of the standard libraries. (You don't want to use it unconditionally, because not all builds are from unmodified GitHub sources.) Use that option in CI. This would need, at least, library team approval.
Rather than using Source Indexing, I would recommend you take a look at Source Link which is a newer, simpler approach to the same concept. With Source Link, you just need to pass a JSON file to the linker which maps local file paths to urls.
I'm still not entirely sure if it's called Source Server or Source Indexing..