[llvm] [XCOFF][OBJECT] get symbol size by calling XCOFF interfaces (PR #67304)

via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 28 10:00:28 PDT 2023


diggerlin wrote:

> > the value of Entry32(Entry64) maybe not be initiated , it will caused getValue() of XCOFFSymbolRef crashed.
> 
> Sorry, I don't quite understand. The `XCOFFSymbolRef` only has one constructor and inside the constructor, the entry is always initialized, so why Entry32(Entry64) may be not initialized when we are using a `XCOFFSymbolRef` object?


If I understand correctly, in your new code in the PR,

```
XCOFFObjectFile::xcoff_symbol_iterator_range XCOFFObjectFile::symbols() const {
  return xcoff_symbol_iterator_range(symbol_begin(), symbol_end());
}
```
it will call 

```
basic_symbol_iterator XCOFFObjectFile::symbol_begin() const {
  DataRefImpl SymDRI;
  SymDRI.p = reinterpret_cast<uintptr_t>(SymbolTblPtr);
  return basic_symbol_iterator(SymbolRef(SymDRI, this));
}
```

SymbolRef(SymDRI, this) only construct the SymbolRef, not XCOFFSymbolRef, so the Entry32/Entry64 of XCOFFSymbolRef is not initiate.  

and also, because xcoff_symbol_iterator -> symbol_iterator ->basic_symbol_iterator =content_iterato\r<BasicSymbolRef\>
 

 when the iterator xcoff_symbol_iterator++ , it will call
  inline void BasicSymbolRef::moveNext() {
  return OwningObject->moveSymbolNext(SymbolPimpl);
}
the value of SymbolPimpl of BasicSymbolRef is updated ,but  Entry32/Entry64 of XCOFFSymbolRef is not updated.

So If some one use iterator of XCOFFObjectFile::symbols() to do something as following, 
```
  if (const auto *E = dyn_cast<XCOFFObjectFile>(&O)) {
    auto Syms = E->symbols();
    for (XCOFFSymbolRef Sym : Syms)
      Sym.getValue() 
```
      
   the value of  Entry32/Entry64 of XCOFFSymbolRef is random, Sym.getValue()  maybe crashed or not correct value.
  
  is it correct ? or I miss some code which can initiate and update the value of Entry32/Entry64 of XCOFFSymbolRef when use the xcoff_symbol_iterator ?
  

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


More information about the llvm-commits mailing list