This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Prelinking on ARM with Debug Link
- 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: Mon, 11 Apr 2016 20:47:00 +0200
- Subject: Re: Prelinking on ARM with Debug Link
- Authentication-results: sourceware.org; auth=none
- References: <4BCA4243-B16B-436F-9D53-41C551492A51 at gmx dot de> <6E47DD0A-0515-45C6-86A1-4669A8182663 at gmx dot de> <1455121041 dot 7606 dot 104 dot camel at redhat dot com> <3855EE25-54F2-47FB-88A8-FF1EC3963C06 at gmx dot de> <1455136517 dot 7606 dot 107 dot camel at redhat dot com> <trinity-fb9190d9-ee29-4674-8066-0251f630d69b-1455187752264 at 3capp-gmx-bs27> <1455617312 dot 9915 dot 50 dot camel at redhat dot com> <1FF3B18B-EEA4-4A00-8E4F-3B7977E0111C at gmx dot de> <1455812509 dot 7770 dot 4 dot camel at redhat dot com> <23DAF1AA-DD74-4B03-8290-A4CB49F10D14 at gmx dot de> <1456246011 dot 7770 dot 120 dot camel at redhat dot com> <97BC1582-878D-4841-9D3B-B0C50A017B1B at gmx dot de> <CBF70205-25B4-4972-8AB5-BC6357618455 at gmx dot de> <8BE9FE12-777D-4C56-89C0-26FC2718CCAE at gmx dot de> <1459516058 dot 8147 dot 138 dot camel at redhat dot com> <ED8344C8-189F-41BF-9780-64DE038ED1B4 at gmx dot de> <1459863878 dot 8147 dot 242 dot camel at redhat dot com> <A15D4550-5249-4235-A89B-ED62327B948E at gmx dot de> <1459979805 dot 8147 dot 274 dot camel at redhat dot com>
Hi Mark,
> Am 06.04.2016 um 23:56 schrieb Mark Wielaard <mjw@redhat.com>:
>
> On Wed, 2016-04-06 at 22:44 +0200, Torsten Polle wrote:
>>> Am 05.04.2016 um 15:44 schrieb Mark Wielaard <mjw@redhat.com>:
>>> runtime/unwind.c (adjustStartLoc):
>>>
>>> if (is_ehframe)
>>> return startLoc + vm_addr;
>>> else
>>> return startLoc + vm_addr - s->sec_load_offset;
>>
>> I had twiddled with the else branch in the past. I do not recall all
>> attempts. But Iâm sure that I set sec_load_offset even to 0. The
>> result is that the probes are set at the wrong address in libc. To be
>> more concrete they are offset by -5184 compared to the original
>> address. Still Iâll check your patch and let you know the result.
>
> This code is certainly confusing. And arm32 might have different
> defaults from all other architectures (which normally have .eh_frames
> instead of just .debug_frames, on arm32 unwinding is often done through
> EXIDX - exception index tables - instead, but stap doesn't support
> those). So it might indeed be that in your case the non-ehframe path is
> taken. But I believe that even in that sec_load_offset should be zero.
Iâve checked your patch. As a result the backtrace calculations break in my environment.
Iâve therefore instrumented adjustStartLoc() as follows:
if (is_ehframe) {
printk(KERN_ERR "eh: s=%lu, v=%lu, l=%lu\n", startLoc, vm_addr, s->sec_load_offset);
return startLoc + vm_addr;
}
else {
printk(KERN_ERR "no eh: s=%lu, v=%lu, l=%lu\n", startLoc, vm_addr, s->sec_load_offset);
return startLoc + vm_addr - s->sec_load_offset;
}
As a result I get the following output:
[ 1215.876537] no eh: s=297684, v=1307279360, l=4294962112
[ 1215.876542] no eh: s=297532, v=1307279360, l=4294962112
[ 1215.876546] no eh: s=297568, v=1307279360, l=4294962112
[ 1215.876551] no eh: s=297612, v=1307279360, l=4294962112
[ 1215.876555] no eh: s=297612, v=1307279360, l=4294962112
[ 1215.876560] no eh: s=297612, v=1307279360, l=4294962112
This means that the non-ehframe path is taken and that sec_load_offset is non-zero.
> So it might impact unwinding through user space shared libraries. But it
> should not impact setting probe points in shared libraries.
>
> On my own setup (x86_64 native) the patch showed no regressions with
> make installcheck. I would be interesting to hear of any test results
> you get with my patch.
>
> Thanks,
>
> Mark
Regards,
Torsten