[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