Re: Prelinking on ARM

[Torsten Polle <Torsten dot Polle at gmx dot de>]

Mark,

Torsten Polle writes:
 > Mark,

 > Mark Wielaard writes:
 >> On Tue, 2015-06-02 at 22:29 +0200, Torsten Polle wrote:
 >>> Am 02.06.2015 um 20:28 schrieb Mark Wielaard <mjw@redhat.com>:
 >>>> On Mon, 2015-06-01 at 22:43 +0200, Torsten Polle wrote:
 >>>>> I've a problem with prelinked shared and non-prelinked debug information
 >>>>> for the same on ARM. The relative offset to the .text section differs
 >>>>> for the prelinked shared library and the non-prelinked debug
 >>>>> information. SystemTap only compensates for the difference in the start
 >>>>> addresses. I tried to debug the problem, but I've to admit that the
 >>>>> problem is well over my head. Could someone give me a hint on this
 >>>>> matter?
 >>>> 
 >>>> Does the testsuite/systemtap.exelib/exelib.exp test work for you?
 >>> 
 >>> I've to check. I'm using a cross compile environment, i.e. I only run
 >>> passes 1 - 4 on my host (X86) and execute staprun on my target
 >>> (ARM). I could provide a small shared library as an example instead.

 >> I must admit to not have much experience with the
 >> cross-compiling/cross-stapping mechanism. If you could provide a
 >> small shared library (plus separate debuginfo file?) and the stap
 >> invocation that doesn't work correctly that would be helpful for
 >> understanding what goes wrong.

please find my example below. Unfortunately, I could not reproduce the
problem with a smaller library. The prelinked library and the debug
information is a little bit larger.

I set a function call and function return probe in function
"__libc_malloc".

In the prelinked file [1], the address is 0x410ddd94. The offset from the load
address is 0x410ddd94 - 0x41068000 = 0x75D94

But the offest given in the debug information is only 0x00074954.

The debug output from SystemTap [3] shows a pc of 0x74954 and a module bias
0x41079440.

[1] prelinked:
objdump -x 
    LOAD off    0x00000000 vaddr 0x41068000 paddr 0x41068000 align 2**15
         filesz 0x0012e268 memsz 0x0012e268 flags r-x
...
  7 .rel.dyn      00003c18  4107b318  4107b318  00013318  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
...
 10 .text         000f3878  4107f080  4107f080  00017080  2**6
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
objdump -T
410ddd94 g    DF .text     00000204  GLIBC_2.4   __libc_malloc
 

[2] debug information:
objdump -x 
    LOAD off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**15
         filesz 0x00000194 memsz 0x0012ce28 flags r-x
 ...
  7 .rel.dyn      00002810  00013318  00013318  00000194  2**2
                  ALLOC, READONLY
...
 10 .text         000f3878  00015c40  00015c40  00000194  2**6
                  ALLOC, READONLY, CODE
...
00074954 g     F .text        00000204 __libc_malloc
 
[3] stap --vp=0800
probe __libc_malloc@/opt/codesourcery/arm-none-linux-gnueabi/src/glibc/malloc/malloc.c:2840 process=/opt/export/arm-root/e03_RFS1/lib/libc-2.18.so reloc=.dynamic pc=0x74954
die parent cache /opt/export/arm-root/e03_RFS1/lib/libc-2.18.so:malloc.c size 726
finding location for local 'bytes' near address 0x74954, module bias 0x41079440

[...]

 > The versions I used for my current tests are:
 > Systemtap translator/driver (version 2.7/0.160, commit release-2.6-199-gd26e62cd8b30)
 > Systemtap translator/driver (version 2.8/0.160, commit release-2.7-166-gae0db08baa54)

 >> Thanks,
 >> Mark

 > Thanks,
 > Torsten

Thanks,
Torsten

Attachment: lib.tar.bz2
Description: BZip2 compressed data