summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/python_api/interpreter/TestCommandInterpreterAPI.py
diff options
context:
space:
mode:
authorZachary Turner <zturner@google.com>2018-11-16 02:42:32 +0000
committerZachary Turner <zturner@google.com>2018-11-16 02:42:32 +0000
commit6284aee9f811d596b941e44b30dee5befbc22f20 (patch)
tree479104d0244245dadeb614f36a02ec44c44f1553 /lldb/packages/Python/lldbsuite/test/python_api/interpreter/TestCommandInterpreterAPI.py
parentab73426c68747fb5221f7ef818de1f71d873dca8 (diff)
downloadbcm5719-llvm-6284aee9f811d596b941e44b30dee5befbc22f20.tar.gz
bcm5719-llvm-6284aee9f811d596b941e44b30dee5befbc22f20.zip
[NativePDB] Rewrite the PdbSymUid to use our own custom namespacing scheme.
Originally we created our 64-bit UID scheme by using the first byte as sort of a "tag" to represent what kind of symbol this was, and we re-used the PDB_SymType enumeration for this. For native pdb support, this is not really the right abstraction layer, because what we really want is something that tells us *how* to find the symbol. This means, specifically, is in the globals stream / public stream / module stream / TPI stream / etc, and for whichever one it is in, where is it within that stream? A good example of why the old namespacing scheme was insufficient is that it is more or less impossible to create a uid for a field list member of a class/struction/union/enum that tells you how to locate the original record. With this new scheme, the first byte is no longer a PDB_SymType enum but a new enum created specifically to identify where in the PDB this record lives. This gives us much better flexibility in what kinds of symbols the uids can identify. llvm-svn: 347018
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/python_api/interpreter/TestCommandInterpreterAPI.py')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud