I've got a fairly large project and I tried to use RemedyBG to debug it. I was able to successfully break into my main function. However I wasn't able to step into various DLL functions.
I suspect the problem is RemedyBG is looking for files in the wrong place. The DLLs were produced by a caching build system. The PDB specified file path doesn't exist on my machine. Although the exactly correct file does exist on my machine.
I don't know that this was the problem. But I encountered the same issue with VS Code so I would not be surprised if RemedyBG had similar issues.
Right now there isn't a way to specify an alternative symbol path. Probably should just read _NT_SYMBOL_PATH at the very least. RemedyBG will, however, attempt to load any PDBs that are the same directory as the binary.
> Right now there isn't a way to specify an alternative symbol path.
The problem is not inability to load PDBs. The problem is that loaded PDBs internally specify a non-existent source file path.
Simple Repro:
1. Build C++ project however you want
2. Configure RemedyBG session to successfully debug
3. Move .cpp file from build location to temp directory
4. RemedyBG can no longer hit breakpoints or step-through .cpp file
In VisualStudio when this happens the editor says "unable to find file foo.cpp. Please specify location.". Upon telling VisualStudio where the file exists you get to debug it. If the file does not match the file used to compile the binary you get a warning.
If you build and debug locally this use case will probably not happen. However there are a few reasonable ways my problem could happen. For example if you want to debug a crashing .exe produced by a build system that clones source code to a different local folder. Or if local builds use a caching build system that pulls compiled artifacts from a cache.