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

Question: Do PDB Sources need Changed for this to work? #2

Closed
JarrodJ83 opened this issue Feb 1, 2022 · 5 comments
Closed

Question: Do PDB Sources need Changed for this to work? #2

JarrodJ83 opened this issue Feb 1, 2022 · 5 comments

Comments

@JarrodJ83
Copy link

JarrodJ83 commented Feb 1, 2022

Thanks for putting together this workaround. It's really frustrating GitLab isn't addressing SourceLink support. Anyway, trying to get this working and had a question. So we have setup the re-writer on a different sub-domain of our gitlab instance. That said since VS uses the git info to pull the url it never goes to the URL which would get re-written. Do you do something in order to point the PDB sources to the URL that the Rewriter is listening on? For example in the readme you use...

https://example.com/token/.....
is rewritten to
https://gitlab.com/api/v4/.....

Wouldn't the PDB Sources need to have https://example.com in them instead of https://gitlab.com in order for this to work correctly?

I'm sure I'm missing something obvious here but have been banging my head on this for some time so hoping to get pointed in the right direction.

Thanks!

@juangburgos
Copy link
Owner

Hi, sorry for the late reply. Just changed jobs and been quite busy. Just a disclaimer; I dont use symbol servers for SoureLink .net apps, but for C++ applications.

So, there are two different things in play here; source servers and symbols servers. When you point VS to a symbol server, it knows how to locate the relevant symbols from this it. But the symbols themselves have embedded URLs for the sources, so then VS try to find the sources from these URLs.

So before you store your symbols into the symbols server, you must index the symbol files, I believe the tool to do that is pdbstr. You must indeed embed the correct (gitlab rewrittee) URLs for VS to find the sources automagically.

@JarrodJ83
Copy link
Author

Ok that makes sense. Glad you could confirm. Much appreciated @juangburgos!

@JarrodJ83
Copy link
Author

One more question, @juangburgos. When re-writing the URL in the PDBs it looks like they need to follow pattern you have listed (https://example.com/token/${gitlab_pa_token}/proj/${project_name}/commit/${commit_hash}/path/${file_path}/file/${file_name}) is that correct? I was hoping I had to just change the git url in the .git/config and let sourcelink do it's thing when creating the PDBs but the more I read into this it doesn't seem it's that simple. Could you confirm?

@juangburgos
Copy link
Owner

The following comes from my personal notes, hope it helps:

Source Indexing

Some Windows Debug Tools, such as WinDBG and Visual Studio, also have the capability to show the source file and line where an unhandled exception happened at the time of an application crash. For this to work, it is not only neccesary to load the correct symbols, but also to point these tools to the exact source files corresponding to the crashed binary version. Handling this manually can also get cumbersome, so the tools can also make use of an index stored inside the symbol files (*.pdb) to retrieve the exact sources automatically from specified locations (i.e. a directory or a web URL). It is possible to manually define such index using the pdbstr tool. The indexing command is:

pdbstr -w -p:${syms_file} -i:${index_file} -s:srcsrv

where,

  • -w -p:${syms_file} : write (-w) into the file (${syms_file}) specified after the -p: flag.

  • -i:${index_file} : use the index file (${index_file}) specified after the -i: flag.

  • -s:srcsrv : access the srcsrv stream (-s).

After the symbol file has been indexed, the index can be read with a similar command using the -r flag:

pdbstr -r -p:${syms_file} -s:srcsrv

The (user defined) index file is simply a text file with the following format:

SRCSRV: ini ------------------------------------------------
VERSION=2
VERCTRL=http
SRCSRV: variables ------------------------------------------
HTTP_ALIAS=${source_server_base_url}
HTTP_EXTRACT_TARGET=%HTTP_ALIAS%%var2%
SRCSRVTRG=%HTTP_EXTRACT_TARGET%
SRCSRV: source files ---------------------------------------
... more files ...
${original_source_path}*${relative_source_path}
... more files ...
SRCSRV: end ------------------------------------------------

where,

  • ${source_server_base_url} : is the base part of the URL used to find the source file e.g. https://myserver.com/repo/commit/. This is complamented with the ${relative_source_path}.

  • ${original_source_path} : is the path of the original source path of the file that was compiled, e.g. c:/users/admin/desktop/../mylib/file.cpp.

  • ${relative_source_path} : is the path of the file relative to the repository root e.g. mylib/file.cpp

Note that the ${source_server_base_url}${relative_source_path} combination must be an existing and accessible URL where the exact source file version used for compilation can be found. This typically points to a source control server URL such as Github or Gitlab.

To create the index file, the challenge is to list all the files used by a given binary, for this, the dbh tool can be used. A bash script that creates the index files can be found in the Appendix of this note.

NOTE : The SRCSRV module of the Microsoft Debug Tools is in charge of resolving the source files, and it has the disadvantage of not supporting URLs with query strings. Gitlab only serves raw files through their API which uses query strings, so a URL proxy is needed that accepts compatible URLs and convert them to Gitlab API URLs. The GitlabRewritter tool does that.

@JarrodJ83
Copy link
Author

Thank you @juangburgos this is very helpful! Much appreciated.

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