This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Prelinking on ARM
- From: Torsten Polle <Torsten dot Polle at gmx dot de>
- To: Mark Wielaard <mjw at redhat dot com>
- Cc: systemtap at sourceware dot org
- Date: Thu, 25 Jun 2015 22:09:44 +0200
- Subject: Re: Prelinking on ARM
- Authentication-results: sourceware.org; auth=none
- References: <m28uc36tyi dot fsf at gmx dot de> <1433269681 dot 4538 dot 237 dot camel at bordewijk dot wildebeest dot org> <3FE8FEB6-F65B-4F42-A963-30B8D216262B at gmx dot de> <1433323679 dot 4538 dot 242 dot camel at bordewijk dot wildebeest dot org> <0FE2ADEE-8F4C-4205-A282-6BE15B8F00D5 at gmx dot de> <B79706AA-26E2-47FF-A8B7-A1545EB7081A at gmx dot de> <1434112811 dot 3016 dot 82 dot camel at bordewijk dot wildebeest dot org>
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