This is the mail archive of the mailing list for the systemtap project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Prelinking on ARM

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.

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?



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]