[all-commits] [llvm/llvm-project] 268089: Fix the encoding and decoding of UniqueCStringMap<...

[Greg Clayton via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 268089b6ac4bca2c87b272a61d7dcc6ad3e752e4
      https://github.com/llvm/llvm-project/commit/268089b6ac4bca2c87b272a61d7dcc6ad3e752e4
  Author: Greg Clayton <gclayton at fb.com>
  Date:   2022-04-29 (Fri, 29 Apr 2022)

  Changed paths:
    M lldb/source/Plugins/SymbolFile/DWARF/NameToDIE.cpp
    M lldb/source/Symbol/Symtab.cpp
    M lldb/unittests/Symbol/SymtabTest.cpp

  Log Message:
  -----------
  Fix the encoding and decoding of UniqueCStringMap<T> objects when saved to cache files.

UniqueCStringMap<T> objects are a std::vector<UniqueCStringMap::Entry> objects where the Entry object contains a ConstString + T. The values in the vector are sorted first by ConstString and then by the T value. ConstString objects are simply uniqued "const char *" values and when we compare we use the actual string pointer as the value we sort by. This caused a problem when we saved the symbol table name indexes and debug info indexes to disk in one process when they were sorted, and then loaded them into another process when decoding them from the cache files. Why? Because the order in which the ConstString objects were created are now completely different and the string pointers will no longer be sorted in the new process the cache was loaded into.

The unit tests created for the initial patch didn't catch the encoding and decoding issues of UniqueCStringMap<T> because they were happening in the same process and encoding and decoding would end up createing sorted UniqueCStringMap<T> objects due to the constant string pool being exactly the same.

This patch does the sort and also reserves the right amount of entries in the UniqueCStringMap::m_map prior to adding them all to avoid doing multiple allocations.

Added a unit test that loads an object file from yaml, and then I created a cache file for the original file and removed the cache file's signature mod time check since we will generate an object file from the YAML, and use that as the object file for the Symtab object. Then we load the cache data from the array of symtab cache bytes so that the ConstString "const char *" values will not match the current process, and verify we can lookup the 4 names from the object file in the symbol table.

Differential Revision: https://reviews.llvm.org/D124572