12

I am using a CMake command to install PDB files to enable debugging in a developer distribution of my C++ application. The command is as below:

INSTALL(DIRECTORY ${PROJECT_BINARY_DIR}/Debug
    DESTINATION bin
    FILES_MATCHING
    PATTERN *.pdb
)

Also, I've managed to install the relevant source used to build that developer distribution, in a 'src' folder at the same level, so that my top level distribution folder looks as:

include\
src\
lib\
bin\
share\
doc\
3rdparty\
etc\

How can I let the PDB files 'know' where the source is (I am assuming this is required)? Is there a CMake command that can achieve this? What would be a small example?

marek.jancuska
  • 310
  • 1
  • 7
squashed.bugaboo
  • 1,338
  • 2
  • 20
  • 36
  • 1
    You might want to take a look at [this question](http://stackoverflow.com/questions/27952/how-do-i-change-the-locations-of-source-files-in-a-symbols-file-pdb). – Angew is no longer proud of SO Feb 19 '13 at 08:12
  • Thanks @Angew - I read the post and the posts from links in it. Do I really have to go through all that symbol server business? I guess what I'm asking is: is there a smart way to package the PDBs and the matching source so that I don't have to do anything else (along the lines of the first answer). – squashed.bugaboo Feb 19 '13 at 14:49
  • 1
    I don't have personal experience with off-site debugging, but the impression I got from all I read about moving PDBs around is that you have to use `subst` or mirror the original source tree exactly. I plan to some day investigate this issue out of curiosity; unfortunately, for rather unclear values of *some day.* – Angew is no longer proud of SO Feb 19 '13 at 14:58
  • By 'mirror the original source tree exactly' I take it you mean that if I package the PDBs and source at the same relative position to each other, as they were when they're built on my local workstation? Is that the case? – squashed.bugaboo Feb 19 '13 at 18:54
  • 1
    Unfortuantely, it seems there are *absolute* path names embedded in the PDB, so these would have to be mirrored. That's why `subst` is suggested. – Angew is no longer proud of SO Feb 20 '13 at 07:57
  • I know how to use the subst command - but it is not quite clear to me what I need to try in this context? Say I am building and packaging my distribution in H:\dist, and in my build-install script I issue subst N: H:\dist before I do my build and install - is that all? Will that automatically embed N:\ into the PDB files? But even if it did, how will that make things work on another developer's workstation since they know nothing about H:\dist or N:\? Would they need to issue the same subst command in some other form - if so what might that be? Or is there more to this than I am reading? – squashed.bugaboo Feb 21 '13 at 16:25
  • 1
    The idea is to do the build on the `N:` drive, so that `N:\ ` is embedded as the root into the PDB files. Then, the other developer has to do `subst` on their machine so that paths to the source on the `N:` drive on his computer are the same as they were on your computer. The the PDBs will work. I.e. if you have a file `C:\MySources\main.cpp` and you did `subst N: C:\MySources`, and if he has a file `D:\Devel\Other\main.cpp`, he will have to do `subst N: D:\Devel\Other` and then work from the `N:` drive as well. – Angew is no longer proud of SO Feb 21 '13 at 17:01
  • Angew..feel free to condense some of your comments into an answer if you'd like and I'll be happy to accept it. – squashed.bugaboo Feb 27 '13 at 23:31
  • Summarized my comments in an answer below. – Angew is no longer proud of SO Mar 04 '13 at 11:26

4 Answers4

19

I just answered my own similar question, How to get CMake to install PDB files for targets.

Use this install rule to copy the target's PDB file, if it exists, to the target's install location bin directory.

install(FILES $<TARGET_PDB_FILE:${PROJECT_NAME}> DESTINATION bin OPTIONAL)
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Phil
  • 5,822
  • 2
  • 31
  • 60
4

PDB files store absolute path names to the source files. When not using a symbol server, the only way to ensure some degree of source code relocatability is to use the subst command.

The idea is to use subst to create a drive-letter name (e.g. N:\) for the root of the source tree. Then do your builds from this drive, so that absolute paths starting with N:\ get embedded into the PDB files. When you later need to debug the executable on a different machine, use subst on that machine to get the same absolute paths to the sources. This will enable the PDB files to find the source files.

For example, if you have a file C:\MySources\main.cpp, do the following:

subst N: C:\MySources
N:
run your build

Later, let's say you need to debug on a machine where the same file is stored in D:\Devel\Other\main.cpp. Simply do subst N: D:\Devel\Other and then work from the N: drive there as well.

This answer is largely based on information from this question and the links therein.

Angew is no longer proud of SO
  • 167,307
  • 17
  • 350
  • 455
  • This scheme cannot be used everywhere. If your organisation is large enough, chances are the drive letter is already used, or you don't have network access. All in all, I consider using substs as a code smell and avoid them. As stated below, by Matt, the IDE will prompt for the source location if need be anyway. – bltxd Sep 20 '18 at 09:56
3

You just need to inform Visual Studio where the source is... It will pop up a file browser dialog; just point to the source on your local machine if the paths differ from when it was built.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Matt
  • 31
  • 1
  • 1
    Indeed, all debuggers are able to load sources from paths different from the ones used at build time. – bltxd Sep 20 '18 at 09:58
0

The PDB file stores the path to the files as they were when the program was compiled. There is nothing you must do to let them know where the source was.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Thomas
  • 4,980
  • 2
  • 15
  • 30
  • Are you sure about this? I mean, if its an absolute path that the PDB file stores (absolute path to the source), then how can it determine that when I package and ship when used on another developer's workstation? If it is relative, then should I make sure that I install the source in a location that is 'relatively' the same to the PDB as it was when built? I hope I make sense.. – squashed.bugaboo Feb 18 '13 at 23:06
  • You could always test this out... Visual Studio (and WinDBG) are both smart enough to map both the location of PDBs and source code. VS will look for PDBs in the same directory as the loaded module (take a look at the modules tab in the debugger too). You can also tell VS where to look via the Debug Options. When you click on a stack call, and if the source is in a different location, VS will prompt you for the location. This even works for crash dumps. How poorly would that scale if we all had to have exactly the same source tree layout? – Tim Finer Jul 20 '16 at 17:35