forked from OSchip/llvm-project
cafd476836
This was originally reported as a bug with the symptom being "cvdump crashes when printing an LLD-linked PDB that has an S_FILESTATIC record in it". After some additional investigation, I determined that this was a symptom of a larger problem, and in fact the real problem was in the way we emitted the global PDB string table. As evidence of this, you can take any lld-generated PDB, run cvdump -stringtable on it, and it would return no results. My hypothesis was that cvdump could not *find* the string table to begin with. Normally it would do this by looking in the "named stream map", finding the string /names, and using its value as the stream index. If this lookup fails, then cvdump would fail to load the string table. To test this hypothesis, I looked at the name stream map generated by a link.exe PDB, and I emitted exactly those bytes into an LLD-generated PDB. Suddenly, cvdump could read our string table! This code has always been hacky and we knew there was something we didn't understand. After all, there were some comments to the effect of "we have to emit strings in a specific order, otherwise things don't work". The key to fixing this was finally understanding this. The way it works is that it makes use of a generic serializable hash map that maps integers to other integers. In this case, the "key" is the offset into a buffer, and the value is the stream number. If you index into the buffer at the offset specified by a given key, you find the name. The underlying cause of all these problems is that we were using the identity function for the hash. i.e. if a string's offset in the buffer was 12, the hash value was 12. Instead, we need to hash the string *at that offset*. There is an additional catch, in that we have to compute the hash as a uint32 and then truncate it to uint16. Making this work is a little bit annoying, because we use the same hash table in other places as well, and normally just using the identity function for the hash function is actually what's desired. I'm not totally happy with the template goo I came up with, but it works in any case. The reason we never found this bug through our own testing is because we were building a /parallel/ hash table (in the form of an llvm::StringMap<>) and doing all of our lookups and "real" hash table work against that. I deleted all of that code and now everything goes through the real hash table. Then, to test it, I added a unit test which adds 7 strings and queries the associated values. I test every possible insertion order permutation of these 7 strings, to verify that it really does work as expected. Differential Revision: https://reviews.llvm.org/D43326 llvm-svn: 325386 |
||
|---|---|---|
| .. | ||
| DIA | ||
| Native | ||
| CMakeLists.txt | ||
| GenericError.cpp | ||
| IPDBSourceFile.cpp | ||
| LLVMBuild.txt | ||
| PDB.cpp | ||
| PDBContext.cpp | ||
| PDBExtras.cpp | ||
| PDBInterfaceAnchors.cpp | ||
| PDBSymDumper.cpp | ||
| PDBSymbol.cpp | ||
| PDBSymbolAnnotation.cpp | ||
| PDBSymbolBlock.cpp | ||
| PDBSymbolCompiland.cpp | ||
| PDBSymbolCompilandDetails.cpp | ||
| PDBSymbolCompilandEnv.cpp | ||
| PDBSymbolCustom.cpp | ||
| PDBSymbolData.cpp | ||
| PDBSymbolExe.cpp | ||
| PDBSymbolFunc.cpp | ||
| PDBSymbolFuncDebugEnd.cpp | ||
| PDBSymbolFuncDebugStart.cpp | ||
| PDBSymbolLabel.cpp | ||
| PDBSymbolPublicSymbol.cpp | ||
| PDBSymbolThunk.cpp | ||
| PDBSymbolTypeArray.cpp | ||
| PDBSymbolTypeBaseClass.cpp | ||
| PDBSymbolTypeBuiltin.cpp | ||
| PDBSymbolTypeCustom.cpp | ||
| PDBSymbolTypeDimension.cpp | ||
| PDBSymbolTypeEnum.cpp | ||
| PDBSymbolTypeFriend.cpp | ||
| PDBSymbolTypeFunctionArg.cpp | ||
| PDBSymbolTypeFunctionSig.cpp | ||
| PDBSymbolTypeManaged.cpp | ||
| PDBSymbolTypePointer.cpp | ||
| PDBSymbolTypeTypedef.cpp | ||
| PDBSymbolTypeUDT.cpp | ||
| PDBSymbolTypeVTable.cpp | ||
| PDBSymbolTypeVTableShape.cpp | ||
| PDBSymbolUnknown.cpp | ||
| PDBSymbolUsingNamespace.cpp | ||
| UDTLayout.cpp | ||