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

clayborg added a comment. I was out on a week long vacation, sorry for the delay. The main questions is: should symbols with NOTYPE actually be included in any address lookups. I would vote for no as how can 1 address resolve to more than one section. That doesn't make sense to me. One address

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

nitesh.jain added a comment. ping https://reviews.llvm.org/D35784 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

clayborg added a comment. maybe lldb::SymbolType::eSymbolTypeCompiler? https://reviews.llvm.org/D35784 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

clayborg added a comment. So the issue is with the ObjectFileELF when it makes its symbol table. It is taking this symbols: 49686: bcf0 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

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

nitesh.jain added a comment. In https://reviews.llvm.org/D35784#820237, @clayborg wrote: > Looking at an ELF file with DWARF, I see: > > (lldb) image dump sections > Dumping sections for 1 modules. > Sections for >

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

clayborg added a comment. Looking at an ELF file with DWARF, I see: (lldb) image dump sections Dumping sections for 1 modules. Sections for '/Volumes/android/aosp/out/target/product/generic/symbols/system/lib/libart.so' (arm): SectID Type File Address

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

clayborg added a comment. (in the above log output .text has a valid address, but .debug_aranges doesn't. We might need to cross correlate withe the program headers to tell if something gets loaded (PT_LOAD) for a given file address. What does the output of: (lldb) image dump sections look

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

clayborg added a comment. In your log we see: [10] .text PROGBITS bb80 bb80 00054380 AX 0 0 16 [30] .debug_arangesMIPS_DWARF 0006c24c 0560 0

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

clayborg requested changes to this revision. clayborg added a comment. This revision now requires changes to proceed. Two issues we need to resolve: - I don't think AddressClass should have Absolute as a value. Absolute values in symbol tables are just numbers, not necessarily addresses. - This

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

nitesh.jain created this revision. Herald added subscribers: arichardson, sdardis. The implementation of Address::GetAddressClass() is based on file address. Those it will give incorrect result if there are more than one section for a particular file address. For example (see attach log), there