feat(debuginfo): Extract srcsrv data from PDB for file mapping#943
feat(debuginfo): Extract srcsrv data from PDB for file mapping#943
Conversation
|
loewenheim
left a comment
There was a problem hiding this comment.
The approach of implementing the remapping as a transformer is fundamentally sound, but I believe the better approach is to integrate it into PdbDebugSession directly. This is for a few reasons:
- The transformer machinery is used in Symbolicator to incorporate information from supplementary files (BCSymbolMaps, il2cpp mapping files) into a symcache. These files are separate from the object file being converted to a symcache. By contrast, in this case, the information is already present in the object file itself.
- Symbolicator doesn't know about different object file types—it relies on
symbolicto convert any object file into a symcache. This information is available to Symbolicator in principle, i.e. it could pattern match on what kind of object file it's dealing with and extract the source server information from PDB objects.
2bc5c37 to
3a14467
Compare
Co-authored-by: Sebastian Zivota <loewenheim@users.noreply.github.com>
Co-authored-by: Sebastian Zivota <loewenheim@users.noreply.github.com>
3a14467 to
a5afa5e
Compare
| let depot_path = var_map.get("var3")?; | ||
| let changelist = var_map.get("var4").map(String::as_str); |
There was a problem hiding this comment.
my only feedback here is that if its expected that the layout uses very specific variables to house the path & revision information, you'll want to likely validate that the revision (changelist here, but I know this means revision) is a valid number (if that positional value exists). Our current layout has these at position 2 & 3 respectively, which means older pdbs from builds before we switch this position will try to map the path as the revision.
Please clearly document this layout:
<Absolute Path>*<User Data, likely Perforce server name>*<Depot Path>*<File Revision>
No description provided.