-
Notifications
You must be signed in to change notification settings - Fork 37
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
Implement GetSymbolStoreFileName #50
Comments
Do you have any tips on how this should be implemented?
Just return the full path to the .dll file? |
Pretty much reverse-engineer native SymReader and do what it does. |
Do you have a pointer to the native source of GetSymbolStoreFileName? Where can I find it? This exception would be nice to fix soon, I'm running into this quite a bit. |
Looks like it's just returning the full path to the .pdb file??
|
CDiaWrapper.GetPdbName does this:
|
I poked around a little bit but couldn't find an easy way to get at the full path to the .pdb (or .dll/.exe in case of embedded .pdb). Feels like to implement this one would need to thread the filepath through somehow. Not sure what's the best way to do it. |
Where is this API used? Some APIs on ISymUnmanagedBinder take the path. So they should probably pass it to SymReader ctor as an optional parameter, so that SymReader can return the path. |
One sample usage is in Mdbg:
When creating a ManagedModule they access and store the .pdb file path. I was thinking about passing through an optional path from the creators of SymReader. It felt a bit dirty as otherwise SymReader is fully isolated from where the symbols came from (stream, file, etc). Maybe still worth it. |
ISymUnmanagedReader is all dirty API :( You can also try to fix Mdbg to not use this API. |
Yup, just worked around it. If I know that the API will throw, why call it in the first place. Going to live with a patched Mdbg for a while. |
Tracking TODO in source
The text was updated successfully, but these errors were encountered: