window/symupload.exe lost support for .pdbs

[GoogleCodeExporter]

symupload only accepts .dll and .exe.

Procedure (Using VC 2003 and Windows Server 2003):
1. Compile a .pdb in release mode (see issue #114)
2. Run "symupload.exe [the_created_pdb].pdb
http://your_server/cgi-bin/your_script.cgi"

expected outcome:
- The symbols are uploaded

real outcome:
- We get a "loadDataForExe failed" message

pdb_source_line_writer.cc was modified at some point and this has broken
the symupload command. See windows/symupload.cc:115 :

====
static bool DumpSymbolsToTempFile(const wchar_t *file,
                                  wstring *temp_file_path,
                                  PDBModuleInfo *pdb_info) {
  google_airbag::PDBSourceLineWriter writer;
  // Use EXE_FILE to get information out of the exe/dll in addition to the
  // pdb.  The name and version number of the exe/dll are of value, and
  // there's no way to locate an exe/dll given a pdb.
>  if (!writer.Open(file, PDBSourceLineWriter::EXE_FILE)) {
    return false;
  }
[...]
====

I believe the proper format here would be "PDBSourceLineWriter::ANY_FILE"
just like we have in the dump_syms tool. If I make this change I get the
expected behavior.

Original issue reported on code.google.com by login_...@yahoo.com on 24 Jan 2007 at 1:03

[GoogleCodeExporter]

This was an intentional change, so that symupload could always supply a proper
version parameter during upload.  That's not possible without getting at the
vsfixedfileinfo structure, which requires access to the exe or dll itself.  
There's
no reasonable way to locate an exe or dll given a pdb.

Original comment by mmento...@gmail.com on 25 Jan 2007 at 12:19

[GoogleCodeExporter]

ok my mistake.

Original comment by login_...@yahoo.com on 25 Jan 2007 at 6:05

[GoogleCodeExporter]

Original comment by mmento...@gmail.com on 28 Sep 2007 at 6:32

• Changed state: Invalid
• Added labels: Component-Tool-SymConverter, OpSys-Windows