You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 27, 2023. It is now read-only.
First, some background. I am currently writing a tool to read and write PDB files related to managed CLR assemblies (and only those). Reading was the easy part, as I can skip most of the PDB infra stuff and just read the actual data. However, I am currently a bit stuck on one specific issue related to writing a PDB file.
This issue occurs when there are name collisions in GLOBALS stream (function/token -ref gets same hash value as some other function/token ref). The most common case for this are constructors, since all managed code constructors are seen as functions named '.ctor' in PDB.
When the hash collision occurs, the order of the items with the same hash seems to matter. If I write out collisioned entries with just some fixed order (e.g. ascending/descending by module index, or something simple like that), things won't work as expected, since then the ISymUnmanagedReader COM object will fail to locate some of the methods part of the collision.
After a bit of digging around, I've found out that only the name of the module seems to affect the order of the items with the same hash value. The token of the function and the order of the functions does not seem to have effect on how the collided entries are sorted in GLOBALS stream. Furthermore, the order seems to stem from some value calculated from the module name, most likely another hash. However, the lhashPbCb function of struct Hasher in PDB\include\misc.h (which is used by GLOBALS stream to hash the names of function/token ref entries themselves) does not seem to provide correct values. The lhashPbCb function of struct HasherV2 in the same file does not seem to be the one used to hash module names, either.
My question is therefore this: what is the logic of ordering the collided entries in GLOBALS stream, at least for the PDB files related to managed code? Can you provide directly the code behind it, or could you explain verbally how the order logic works? This seems, at the moment at least, one last issue preventing me from creating PDB file which is readable by ISymUnmanagedReader.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi,
First, some background. I am currently writing a tool to read and write PDB files related to managed CLR assemblies (and only those). Reading was the easy part, as I can skip most of the PDB infra stuff and just read the actual data. However, I am currently a bit stuck on one specific issue related to writing a PDB file.
This issue occurs when there are name collisions in GLOBALS stream (function/token -ref gets same hash value as some other function/token ref). The most common case for this are constructors, since all managed code constructors are seen as functions named '.ctor' in PDB.
When the hash collision occurs, the order of the items with the same hash seems to matter. If I write out collisioned entries with just some fixed order (e.g. ascending/descending by module index, or something simple like that), things won't work as expected, since then the ISymUnmanagedReader COM object will fail to locate some of the methods part of the collision.
After a bit of digging around, I've found out that only the name of the module seems to affect the order of the items with the same hash value. The token of the function and the order of the functions does not seem to have effect on how the collided entries are sorted in GLOBALS stream. Furthermore, the order seems to stem from some value calculated from the module name, most likely another hash. However, the
lhashPbCb
function of structHasher
inPDB\include\misc.h
(which is used by GLOBALS stream to hash the names of function/token ref entries themselves) does not seem to provide correct values. ThelhashPbCb
function of structHasherV2
in the same file does not seem to be the one used to hash module names, either.My question is therefore this: what is the logic of ordering the collided entries in GLOBALS stream, at least for the PDB files related to managed code? Can you provide directly the code behind it, or could you explain verbally how the order logic works? This seems, at the moment at least, one last issue preventing me from creating PDB file which is readable by ISymUnmanagedReader.
The text was updated successfully, but these errors were encountered: