[llvm] [llvm-symbolizer] nfc, use map instead of vector (PR #69552)

Chen Zheng via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 25 00:46:46 PDT 2023


================
@@ -82,12 +82,8 @@ class SymbolizableObjectFile : public SymbolizableModule {
     // Non-zero if this is an ELF local symbol. See the comment in
     // getNameFromSymbolTable.
     uint32_t ELFLocalSymIdx;
-
-    bool operator<(const SymbolDesc &RHS) const {
-      return Addr != RHS.Addr ? Addr < RHS.Addr : Size < RHS.Size;
-    }
   };
-  std::vector<SymbolDesc> Symbols;
+  std::map<uint64_t, SymbolDesc> Symbols;
----------------
chenzheng1030 wrote:

> Why do you need to know this at insertion time rather than just sorting things differently?

Because of the data we stored to `Symbols`. For now, The symbol is stored as:
```
  struct SymbolDesc {
    uint64_t Addr;
    // If size is 0, assume that symbol occupies the whole memory range up to
    // the following symbol.
    uint64_t Size;

    StringRef Name;
    // Non-zero if this is an ELF local symbol. See the comment in
    // getNameFromSymbolTable.
    uint32_t ELFLocalSymIdx;

    bool operator<(const SymbolDesc &RHS) const {
      return Addr != RHS.Addr ? Addr < RHS.Addr : Size < RHS.Size;
    }
  };
```

When we do the sorting, we need to know some symbol flags besides address and size for XCOFF. See the comments here https://github.com/llvm/llvm-project/pull/69553/files#diff-795c0eb20ded2ff47056aa629fc0e183c20225b8fd40b607627ab3106995779dR222-R225

Is it acceptable to you that we add a new element (maybe a `SymbolRef` type and can eliminate current field `ELFLocalSymIdx`) in `struct SymbolDesc`? If using this way, we don't need to change the container, can still use vector and do the sort once.

https://github.com/llvm/llvm-project/pull/69552


More information about the llvm-commits mailing list