Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add path mapping in dump_syms #37

Open
calixteman opened this issue Nov 18, 2019 · 3 comments
Open

Add path mapping in dump_syms #37

calixteman opened this issue Nov 18, 2019 · 3 comments

Comments

@calixteman
Copy link
Collaborator

According to some rules we should make path mapping (hg/s3 see https://searchfox.org/mozilla-central/source/toolkit/crashreporter/tools/symbolstore.py) in dump_syms.

@luser
Copy link

luser commented Mar 18, 2020

This is primarily used for crash-stats to make links back to the source repo but that script does also use the same mappings to add source indexing to PDB files so that the source server works when debugging on Windows. (Ideally you'd have the ability to write a new PDB stream without having to invoke pdbstr but I don't think the pdb crate has that functionality currently.)

@luser
Copy link

luser commented Jul 29, 2020

There are 3 important bits to this:

  1. Using the install manifests from the build system to map files from e.g. dist/include back to their original locations in the source tree. (Resolving symlinks would suffice on non-Windows builds.)
  2. Using the list of known generated source files to map generated sources to point at the s3 bucket where they get uploaded.
  3. Mapping in-tree sources to point to the hg repo.

@luser
Copy link

luser commented Nov 17, 2021

Oh, there's a useful 4th bit I forgot, which is that the script (or maybe configure, I forget) asks rustc what git revision it was built from, and uses that to remap source paths from the Rust standard library into the rust-lang/rust GitHub repo. rustc binaries are built with path remapping so source paths in the debug info include a known prefix + the git hash.

The primary reason this was all done in the Python script is because it's all extremely Mozilla-specific and I couldn't justify trying to upstream it. Most of the info is also just easier to get via the mozbuild APIs and whatnot in Python than via other means.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants