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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits