Reading stack trace with addr2line

[Miha]

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.

[mic _]

Did you try subtracting 0x81800000 from those addresses?  

/Michael

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[Miha]

Hey Michael!

> Did you try subtracting 0x81800000 from those addresses?

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.

[mic _]

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

 Miha.

[Miha]

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.

[David Turner]

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 Mon, Oct 24, 2011 at 9:00 PM, Miha <miha.v...@gmail.com> wrote:

[Miha]

On Oct 25, 2:19 pm, David Turner <di...@android.com> wrote:
> Shared libraries are loaded at random memory addresses by the system. To

>      #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

Yes. And I can lookup 00015760 using addr2line tool.

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

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.