Re: Prelinking on ARM

[Torsten Polle <Torsten.Polle@gmx.de>]

Hi Mark,

Mark Wielaard writes:
 > Hi Torsten,

 > On Fri, 2015-06-05 at 21:55 +0200, Torsten Polle wrote:
 >> >> 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.

 > That might, or might not, be correct. systemtap uses libdwfl to create a
 > memory layout mimicking how the process/library may be placed in memory.
 > It might pick a (fictional) load address for the library that is
 > different than what the dynamic loader might pick (the prelinked load
 > address). If so, that might explain the difference of module bias.

I've to apologies for my late answer.

I double checked my example again and again. I took a HW debugger to
check the place where kprobes set the "breakpoint" in the library. To my
embarassement SystemTap or better libdwfl is performing the right
calculations. The probe hit again. Since I'm very sure that I had a
cases where probes were not hit, I tried various ways to reproduce the
failure. Again without success.

 > It does look to me like the pc address that stap finds (0x74954) is
 > correct for the malloc function you are trying to probe.

 > Could you show the complete stap command line you are using?
 > What do you expect the output is and what does the full output actually
 > look like?

 > Thanks,

 > Mark

Thanks for your support,
Torsten