Wrong base address calculation for stripped Android libraries

[GoogleCodeExporter]

In the current AOSP master, stripped libraries have this virtual address bias 
(ex. libart.so):

  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x0000d000 0x0000d000 0x40e304 0x40e304 R E 0x1000
  LOAD           0x40e9d8 0x0041c9d8 0x0041c9d8 0x0a230 0x0bf8d RW  0x1000

Compare with unstripped:

  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00000000 0x00000000 0x41b304 0x41b304 R E 0x1000
  LOAD           0x41b9d8 0x0041c9d8 0x0041c9d8 0x0a230 0x0bf8d RW  0x1000

This results in module offsets (in unsymbolized stack traces) being off by 
0xd000.

This could be fixed in llvm-symbolizer, but that would cause discrepancy 
between add2line and llvm-symbolizer input formats.

On Android we use MemoryMappingLayout::DumpListOfModules to calculate module 
offsets. Extracting this 0xd000 offset from /proc/*/maps seems impossible (it's 
just not there).

Compare with dl_iterate_phdr_cb (phdr->p_vaddr calculation).

Original issue reported on code.google.com by euge...@google.com on 28 Apr 2015 at 6:05

[GoogleCodeExporter]

Interesting. There is dl_iterate_phdr in the ToT libdl.so on ARM.

Original comment by euge...@google.com on 28 Apr 2015 at 6:08

[GoogleCodeExporter]

So... where did you get this description of LOAD segments from? Is there smth. 
similar to dl_iterate_phdr on Android we can use to precisely calculate the 
actual offsets?

Original comment by samso...@google.com on 28 Apr 2015 at 6:09

[GoogleCodeExporter]

r236014.

Original comment by euge...@google.com on 28 Apr 2015 at 6:53

• Changed state: Fixed