window/symupload.exe lost support for .pdbs
Closed this issue · 3 comments
GoogleCodeExporter commented
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 commented
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 commented
ok my mistake.
Original comment by login_...@yahoo.com
on 25 Jan 2007 at 6:05
GoogleCodeExporter commented
Original comment by mmento...@gmail.com
on 28 Sep 2007 at 6:32
- Changed state: Invalid
- Added labels: Component-Tool-SymConverter, OpSys-Windows