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
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
