In D96766#2596701, @labath wrote:

Hm.... I'm very tempted to delete the linux mips implementation -- it uses several techniques which are getting in the way of this patch (and also some others in the past), for a lot of those, we now have different/better ways of doing it. On top of that, it's completely unmaintained (last non-nfc change to the file was in 2017, and the author (@nitesh.jain) does not appear to be active anymore.

Update diff as per suggestion.

Updated diff as per suggestion

ping

SANITIZER_COMMON_CFLAGS is defined somewhere else in compiler-rt. It already should be including the CMAKE_C_FLAGS into its definition, so I'm confused why we even need this change.

Update diff as per suggestion

Hi Simon,

Fix unit test build issues.

LGTM.

Thanks Simon.

Update diff as per suggestion. Thanks Greg for your suggestion.

The $debug_rangesN symbols are added by linker. These symbols are not used anywhere We can skip these type of symbols (where symbol type is STT_NOTYPE and its section is Debug)

Fix Format.

Update diff as per suggestion

In D11465#826132, @tberghammer wrote:

Thanks for all of the data. Based on this I think you are using a preview version of android O what reports SDK 25 but the linker works the way an SDK 26 system linker would do.

I think the proper fix for the problem is to do something like what Greg suggested to detect the correct function name based on the list of available symbols instead of based on the SDK version. I will try to create a CL to fix it in the next couple of days (unless you are happy to do it), but not sure when I will have time for that and it is a bit tricky to test it.

Until then you can try to do either update to a newer version of the system image what reports SDK 26 (and make sure you are using a sufficiently new LLDB) or locally hack the "PlatformAndroid::LoadImage" function to use the SDK 26 version in case of SDK 25 as well (possibly with a check for ro.build.version.release)

Please could you find some time to look into this ?

The android version am using for testing is "O".

Hi Tamas,

In 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.

In D35784#820237, @clayborg wrote:

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                             Perm File Off.  File Size  Flags      Section Name
  ---------- ---------------- ---------------------------------------  ---- ---------- ---------- ---------- ----------------------------
  0x00000001 regular                                                   ---  0x00000000 0x00000000 0x00000000 libart.so.
  0x00000002 regular          [0x0000000000000154-0x0000000000000167)  r--  0x00000154 0x00000013 0x00000002 libart.so..interp
  0x00000003 elf-dynamic-symbols [0x0000000000000168-0x0000000000010d18)  r--  0x00000168 0x00010bb0 0x00000002 libart.so..dynsym
  0x00000004 regular          [0x0000000000010d18-0x000000000005228f)  r--  0x00010d18 0x00041577 0x00000002 libart.so..dynstr
  0x00000005 regular          [0x0000000000052290-0x000000000005a590)  r--  0x00052290 0x00008300 0x00000002 libart.so..hash
  0x00000006 elf-relocation-entries [0x000000000005a590-0x0000000000067870)  r--  0x0005a590 0x0000d2e0 0x00000002 libart.so..rel.dyn
  0x00000007 elf-relocation-entries [0x0000000000067870-0x0000000000068398)  r--  0x00067870 0x00000b28 0x00000002 libart.so..rel.plt
  0x00000008 regular          [0x0000000000068398-0x0000000000069468)  r-x  0x00068398 0x000010d0 0x00000006 libart.so..plt
  0x00000009 code             [0x0000000000069470-0x00000000002a94f8)  r-x  0x00069470 0x00240088 0x00000006 libart.so..text
  0x0000000a ARM.exidx        [0x00000000002a94f8-0x00000000002b12d0)  r--  0x002a94f8 0x00007dd8 0x00000082 libart.so..ARM.exidx
  0x0000000b ARM.extab        [0x00000000002b12d0-0x00000000002b1e44)  r--  0x002b12d0 0x00000b74 0x00000002 libart.so..ARM.extab
  0x0000000c regular          [0x00000000002b1e48-0x00000000002e39e4)  r--  0x002b1e48 0x00031b9c 0x00000002 libart.so..rodata
  0x0000000d eh-frame         [0x00000000002e39e4-0x00000000002e5fa8)  r--  0x002e39e4 0x000025c4 0x00000002 libart.so..eh_frame
  0x0000000e regular          [0x00000000002e5fa8-0x00000000002e63d4)  r--  0x002e5fa8 0x0000042c 0x00000002 libart.so..eh_frame_hdr
  0x0000000f regular          [0x00000000002e7e38-0x00000000002eaa24)  rw-  0x002e6e38 0x00002bec 0x00000003 libart.so..data.rel.ro.local
  0x00000010 regular          [0x00000000002eaa24-0x00000000002eaa28)  rw-  0x002e9a24 0x00000004 0x00000003 libart.so..fini_array
  0x00000011 regular          [0x00000000002eaa28-0x00000000002ee370)  rw-  0x002e9a28 0x00003948 0x00000003 libart.so..data.rel.ro
  0x00000012 regular          [0x00000000002ee370-0x00000000002ee3c0)  rw-  0x002ed370 0x00000050 0x00000003 libart.so..init_array
  0x00000013 elf-dynamic-link-info [0x00000000002ee3c0-0x00000000002ee4f0)  rw-  0x002ed3c0 0x00000130 0x00000003 libart.so..dynamic
  0x00000014 regular          [0x00000000002ee4f4-0x00000000002ef000)  rw-  0x002ed4f4 0x00000b0c 0x00000003 libart.so..got
  0x00000015 data             [0x00000000002ef000-0x00000000002ef8c4)  rw-  0x002ee000 0x000008c4 0x00000003 libart.so..data
  0x00000016 zero-fill        [0x00000000002ef8c8-0x00000000002f11fc)  rw-  0x002ee8c8 0x00000000 0x00000003 libart.so..bss
  0x00000017 regular                                                   ---  0x002ee8c4 0x00000010 0x00000030 libart.so..comment
  0x00000018 dwarf-line                                                ---  0x002ee8d4 0x002c10eb 0x00000000 libart.so..debug_line
  0x00000019 dwarf-info                                                ---  0x005af9bf 0x054eb22a 0x00000000 libart.so..debug_info
  0x0000001a dwarf-abbrev                                              ---  0x05a9abe9 0x000f5e5b 0x00000000 libart.so..debug_abbrev
  0x0000001b dwarf-aranges                                             ---  0x05b90a48 0x00011960 0x00000000 libart.so..debug_aranges
  0x0000001c dwarf-loc                                                 ---  0x05ba23a8 0x00a0d623 0x00000000 libart.so..debug_loc
  0x0000001d dwarf-ranges                                              ---  0x065af9cb 0x0029c7b0 0x00000000 libart.so..debug_ranges
  0x0000001e dwarf-macro                                               ---  0x0684c17b 0x000ada15 0x00000000 libart.so..debug_macro
  0x0000001f dwarf-str                                                 ---  0x068f9b90 0x004a45e9 0x00000030 libart.so..debug_str
  0x00000020 dwarf-frame                                               ---  0x06d9e17c 0x0003fc6c 0x00000000 libart.so..debug_frame
  0x00000021 regular                                                   ---  0x06dddde8 0x0000001c 0x00000000 libart.so..note.gnu.gold-version
  0x00000022 regular                                                   ---  0x06ddde04 0x00000038 0x00000000 libart.so..ARM.attributes
  0x00000023 elf-symbol-table                                          ---  0x06ddde3c 0x00056c30 0x00000000 libart.so..symtab
  0x00000024 regular                                                   ---  0x06e34a6c 0x0006c9e6 0x00000000 libart.so..strtab
  0x00000025 regular                                                   ---  0x06ea1452 0x0000017b 0x00000000 libart.so..shstrtab

Note how all DWARF sections have no file address. They are known to not be valid addresses. Are you seeing something different with your ELF file? Or do you have two ELF files? One without symbols and one with? The output of "image dump sections" should look like above where no DWARF sections have anything valid in the "File Address" column.

In D35555#819832, @sdardis wrote:

Nitesh, can you commandeer this?

Thanks,
Simon

Update diff as per suggestion.

Hi Ki,

Update Diff as per suggestion

Update diff as per suggestion

In D32125#736543, @sdardis wrote:

Hi Nitesh,

this commit broke clang-cmake-mips. Can you investigate?

http://lab.llvm.org:8011/builders/clang-cmake-mips/builds/3189

Thanks,
Simon

In D32125#734500, @emaste wrote:

In D32125#728166, @krytarowski wrote:

Is this just GNU specific? BSD moved to 64-bit off_t on 32-bit platforms 20+ years ago.

It's perhaps no-op, but it might be noted in the commit message what platforms are supposed to be improved.

I'd say it's better to put a comment in the source where it's set.

In D32340#733387, @ki.stfu wrote:

Thanks for catching this! Could you update this CL to let me commit it?

Update diff as per suggestion.

In D32125#728166, @krytarowski wrote:

Is this just GNU specific? BSD moved to 64-bit off_t on 32-bit platforms 20+ years ago.

It's perhaps no-op, but it might be noted in the commit message what platforms are supposed to be improved.

Update diff as per suggestion.

Update diff as per suggestion.

The core architecture doesn't have any revision, os and ABI information. Hence we need to relied on target architecture.

updated diff as per suggestion

They are around ~28KB

Added test case for MIPS in https://reviews.llvm.org/D31280

In case of MIPS, The ELFLinuxPrPsInfo.pr_uid and ELFLinuxPrPsInfo.pr_gid is always 32 bit irrespective of platforms

In D30457#694306, @labath wrote:

Thank you for updating that. Let me know what the make_core investigation uncovers.

Update Diff as per suggestion

In case of debugging normal process, the memory_info.GetName() is not empty and hence module is read from memory (m_process->ReadModuleFromMemory) and the corresponding sections are updated. In case of core file , the memory_info.GetName() is empty which causes FindFirstModule to matches with the first module in ModuleSpecList and result in loading wrong module at incorrect sections addresses. This patch regain "vdso" module name if memory_info.GetName() is empty.

In D30454#693614, @clayborg wrote:

So a ModuleSpec allows you to specify a module by path, UUID and many other things. This is falling down for a magic file that doesn't actually exist right?

The .note.ABI-tag is missing in the ELF file, generated by test/testcases/functionalities/postmortem/elf-core/make-core.sh. Need to look into it.

Update diff as per suggestion.

Attach log file

The issue was observed while parsing "vdso module" for the core file. When the DynamicLoader::LoadModuleAtAddress is called to load "vdso" module. Since "vdso" doesn't match with any of the module in the target.GetImages(), the check_alternative_file_name becomes true. This cause MatchesModuleSpec to return true and application binary to reload again at vdso base address(AT_SYSINFO_EHDR) thus all load addresses of application elf's sections becomes incorrect. Please find attach log file.
DynamicLoader::LoadModuleAtAddress(...)
{

...
...
...
if (check_alternative_file_name) {
        ...
        ...
        ...
        **FileSpec(memory_info.GetName().AsCString(), false),**  ** // memory_info.GetName().AsCString() is empty here**
        target.GetArchitecture());