1

I need to get the filenames from a PDB file which correspond to variables in unnamed namespaces. I'm using VS2012 and C++. I have put together a small sample of trivial code to illustrate the problem:

// file: unnamed_namespace1.cpp Minimal test for anonymous namespace symbols

namespace {
float x;
static float xx;
}

int unnamed_namespace1(int data) {
    x = 1.0f;
    if (data == 0) {
        // Computation
        xx = x;
    } else {
        xx = 0.0;
    }

    return 1;
}

// file unnamed_namespace2.cpp Minimal test for anonymous namespace symbols

namespace {
float x;
float y;
float z;
static float xx;
static float yy;
static float zz;
}

int unnamed_namespace2(int data) {
x = 1.0f;
if (data == 0) {
    // Computation
    xx = x;
} else {
    xx = 0.0;
}

return 2;
}

// file main.cpp
#include <iostream>
using std::cout;
using std::endl;

int unnamed_namespace1(int data);
int unnamed_namespace2(int data);

int main(int /* argc */, char** /* argv */) {
    int r1 = unnamed_namespace1(0);
    cout << "r1=" << r1 << endl;
    int r2 = unnamed_namespace2(1);
    cout << "r2=" << r2 << endl;
}

I need some way to look into the PDB file and get enough information to discriminate between the two instances of x and xx in the separate compilands.

I downloaded and played a bit with a project called dia2dump (from https://msdn.microsoft.com/en-us/library/b5ke49f5.aspx), which did help a bit with understanding how the DIA system works, in contrast to the MSDN "documentation" on IDiaSymbol which mostly lacks any context, and has very little in the way of meaningful code examples.

It appears that there is not a good way to tie the symbols x and xx back to the source file names.

I can get an IDiaSymbol* pSymbol, but the various functions that look like they might actually provide what I need all return S_FALSE: "A return value of S_FALSE means the property is not available for the symbol."

Here's a snippet of some code I inserted in dia2dump:

    BSTR bstrFname;

    if (pSymbol->get_sourceFileName(&bstrFname) == S_OK) {
        wprintf(L"fn:%s ", bstrFname); // <== never gets here

        SysFreeString(bstrFname);
    }else{
        wprintf(L"no fn "); // <== this is always printed
    }

I was unable to locate any clues for why get_sourceFileName() doesn't return anything useful.

I'm guessing that I'm either 1) looking in the wrong place, or 2) the programmers who wrote the Debug Interface Access DLL didn't consider it important enough to implement that feature for symbols in anonymous namespaces. I'm hoping it's #1, so that somebody out there can point out whatever it is that I have managed to overlook.

It's even ok to make fun of my ignorance, as long as you provide usable information...

  • On further exploration, it appears that file/compiland information for globals is not stored in the PDB, period (either in unnamed namespaces, or otherwise). You can get a unique ID number, and you can get an RVA, for global data symbols, but there does not appear to be any way to track either of those back to the compiland. Apparently, this functionality was just not implemented. – Howard Lee Harkness Sep 08 '15 at 16:21
  • Interesting. What are your pdb-specific command line switches to the compiler? Which optimizations did you turn on? Can you retry without optimization and maximum debug output? – Thomas Weller Sep 17 '15 at 15:13
  • I found a workaround. I discovered that IDiaSymbol::get_relativeVirtualAddress() furnishes a unique address which I can put into a map associated with the name of the file I'm currently parsing (during the first pass, when I have access to the compiland name). Then later, when I need to look up that file name, I can call IDiaSymbol::get_relativeVirtualAddress() for the symbol, and use that address to get the compiland for the symbol. That enabled me to differentiate between symbols in unnamed namespaces in different files. – Howard Lee Harkness Dec 17 '15 at 15:52
  • The command-line switches don't appear to have anything specific to PDBs except for the output pdb file name. I didn't set those up; they were from a few years ago. – Howard Lee Harkness Dec 17 '15 at 16:09

0 Answers0