[Lldb-commits] [PATCH] D35784: [LLD][MIPS] Fix Address::GetAddressClass() to return correct AddressClass based on the load address

[Nitesh Jain via Phabricator via lldb-commits]

nitesh.jain added a comment.

In https://reviews.llvm.org/D35784#823131, @clayborg wrote:

> So the issue is with the ObjectFileELF when it makes its symbol table. It is taking this symbols:
>
>   49686: 000000000000bcf0 0 NOTYPE LOCAL DEFAULT 40 $debug_ranges627
>
>
> And saying it is a code symbol. This symbols has a NOTYPE on it, not FUNC like the main symbol. Fix the ObjectFileELF to give an appropriate lldb::SymbolType value for it. It shouldn't be lldb::SymbolType::eSymbolTypeCode. So set all NOTYPE to lldb::SymbolType::eSymbolTypeInvalid or add a new enum that makes sense.


For the $debug_ranges627 we are getting correct symbol type i.e lldb::SymbolType::eSymbolTypeInvalid.  The function Symbol::FindSymbolAtFileAddress(lldb::addr_t file_addr) search for the symbol with file_addr. These return symbol $debug_ranges627 lldb::SymbolType::eSymbolTypeInvalid . Actual symbol what we want for address **//0xbcf0//** was main symbol but RangeDataVector::FindEntryThatContains(B addr) return $debug_ranges627 .

000000000000**//bcc4//** 1664 FUNC GLOBAL DEFAULT 10 main

Should we add  FindSymbolContainingFileAddressAndType() which will return correct symbol based on Type ?

The ObjectFile::GetAddressClass(addr_t file_addr) {

  Symtab *symtab = GetSymtab();
  if (symtab) {
    Symbol *symbol = symtab->FindSymbolContainingFileAddress(file_addr); // symtab->FindSymbolContainingFileAddressAndType(file_addr, eSymbolTypeCode)
    if (symbol) {
    ...
    ...
    ...
    }
  ...
  ...
  ...

}
...
...
...
}


https://reviews.llvm.org/D35784