Hi!

I have some troubles understanding the native stack traces. For
instance, I can lookup function names where stack trace looks like
this:

      #00  pc 00015760 /data/data/si.my.prog/lib/libbridge.so
      #01  lr 81980a84  /data/data/si.my.prog/lib/libbridge.so

using addr2line, but what when the stack trace data contains memory
locations:

#00 4719fc50  00000003
    4719fc54  001c1408
    4719fc58  002530c4
    4719fc5c  002530c4
    4719fc60  81bd1ffc  /data/data/si.my.prog/lib/libbridge.so

Can I somehow get the location of the function in my library from
runtime memory address 0x81bd1ffc? Is there a way to convert
0x81bd1ffc to pc address like 0x000_____?

Thanks,
 Miha.

Did you try subtracting 0x81800000 from those addresses?

/Michael

Hey Michael!

This produces some results (I'm not sure if it is correct, but I am
actually getting the function names resolved!). Whohoo! :)

Is 0x81800000 some magical number?

Regards,
 Miha.

It just looked to me like that's what your addresses were offset by.
I'm not very familiar with the shared object / ELF format, but if it's
anything like PE there would be a virtual base address somewhere in the
header that specifies where the library wishes to be loaded.

/Michael

Michael, I'm not sure I really understand what you're saying, although
I'm very intrigued by the idea I could find out just by reading the SO
file.

I've dumped all headers using objdump -x but there are no entries
which even start with 8xxx address:
ISLAlwaysOn/IslAlwaysOn/native/lib/libandroid-bridge.so:     file
format elf32-little
ISLAlwaysOn/IslAlwaysOn/native/lib/libandroid-bridge.so
architecture: UNKNOWN!, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x00140178

Program Header:
0x70000001 off    0x00426670 vaddr 0x00426670 paddr 0x00426670 align
2**2
         filesz 0x0001b318 memsz 0x0001b318 flags r--
    LOAD off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align
2**12
         filesz 0x00441988 memsz 0x00441988 flags r-x
    LOAD off    0x00442000 vaddr 0x00442000 paddr 0x00442000 align
2**12
         filesz 0x0000887c memsz 0x0001aa3c flags rw-
 DYNAMIC off    0x00446274 vaddr 0x00446274 paddr 0x00446274 align
2**2
         filesz 0x000000d0 memsz 0x000000d0 flags rw-
   STACK off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align
2**2
         filesz 0x00000000 memsz 0x00000000 flags rw-

The readelf -a also doesn't contain anything similar to 0x8...:
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x140178
  Start of program headers:          52 (bytes into file)
  Start of section headers:          28985332 (bytes into file)
  Flags:                             0x4000002, has entry point,
Version4 EABI
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         5
  Size of section headers:           40 (bytes)
  Number of section headers:         31
  Section header string table index: 28

I've used the android ndk specific versions of readelf and objdump...

Thanks,
 MIha.

On Oct 25, 11:35 am, mic _ <micol...@gmail.com> wrote:

Shared libraries are loaded at random memory addresses by the system. To
make reading stack-traces easier, the trace dumper will print offsets,
instead of real addresses when displaying code addresses, i.e. after a "pc"
(for ARM) or "eip" (for x86) value. For example, in

     #00  pc 00015760 /data/data/si.my.prog/lib/libbridge.so
     #01  lr 81980a84  /data/data/si.my.prog/lib/libbridge.so

the number after "pc" is an offset in the libbridge.so file
the number after "lr" is a memory address corresponding to the same file
(fact is that "lr" can be used as a general purpose register, so the trace
dumper doesn't try to "translate it" automatically).

when displaying stack content, only memory addresses are displayed.

If you want to know the real difference, look at the real value of "pc" in
the register dump, and substract the 00015760 above.

On Oct 25, 2:19 pm, David Turner <di...@android.com> wrote:

Yes. And I can lookup 00015760 using addr2line tool.

The value of PC register is "81bc329a". The first values are easy to
lookup using addr2line (the ones prefixed with #00, #01 and #02,
because they are relative).
         #00  pc 003c329a  /data/data/si.xlab.android.aon/lib/
libandroid-bridge.so
         #01  pc 00011a0c  /system/lib/libc.so
         #02  pc 0001174c  /system/lib/libc.so
But below in the stack, there is this line:
    47223eec  81abe368  /data/data/si.xlab.android.aon/lib/libandroid-
bridge.so
This is what you describe a random address in the memory. This was
puzzling until you pointed the subtraction method.

So I should subtract: 0x81bc329a - 0x003c329a = 0x8180000. OK, so this
explains the "magic" number Michael pointed out, now with an
explanation where it came from! And yes, when subtracting 0x81800000
from 0x81abe368 I indeed get a function within my library!
Excellent! :)

Thank you!

Regards,
 Miha.