This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Prelinking on ARM with Debug Link
- From: Mark Wielaard <mjw at redhat dot com>
- To: Torsten Polle <Torsten dot Polle at gmx dot de>
- Cc: systemtap at sourceware dot org
- Date: Wed, 13 Apr 2016 11:25:10 +0200
- Subject: Re: Prelinking on ARM with Debug Link
- Authentication-results: sourceware.org; auth=none
- References: <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> <D9911106-AB0E-4947-ADC9-F8CFB8700226 at gmx dot de> <20160411210157 dot GA4882 at blokker dot redhat dot com> <4ED55041-059E-44FE-98F3-4C39E08E11BA at gmx dot de>
Hi Torsten,
On Tue, 2016-04-12 at 22:26 +0200, Torsten Polle wrote:
> > Am 11.04.2016 um 23:01 schrieb Mark Wielaard <mjw@redhat.com>:
> >
> > On Mon, Apr 11, 2016 at 08:47:00PM +0200, Torsten Polle wrote:
> >> Iâve checked your patch. As a result the backtrace calculations
> >> break in my environment.
> >
> > I assume this is an in-kernel backtrace, does it involve kernel
> modules?
> > Or is it a user backtrace, executable only? shared libraries?
> > Could you show a probe script and example backtrace?
>
> in principle, Iâm talking about the example in [1]. In short, Iâm
> talking about getting a proper backtrace in the prelinked library
> libc-2.18.so. Iâm saying âin principleâ because the example does not
> set a real probe, but only makes SystemTap include the necessary
> unwinding information for libc-2.18.so.
>
> The real (actually already stripped down) script can be found in [2].
>
> In the script taptrek_run_izA4.stp in line 240, Iâm using the
> following statement
> uaddr = __ustack_raw(depth);
> to get backtrace information. Please donât get distracted by the usage
> of the function __ustack_raw(). The function print_ubacktrace() would
> provide a similar result.
I am not sure why the example needs to be so complicated.
The usage of mixed user/kernel space probes/backtraces makes it really
hard to understand what is going on. Can't you show what you get with a
simple probe inside libc.so with a print_ubacktrace?
> > Please do include some verbose output. If you can provide the output
> > of stap -DDEBUG_UNWIND=1 that might be helpful.
>
> Iâll try my best and come back to you. I would provide the information with my patch applied, because otherwise the result is simply garbage.
Please do include the exact patch you are using.
> > 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.
> >
> > And that calculation wraps around because it is all unsigned.
> > I admit I don't understand what this calculation represents.
>
> s=297612 = 0x48A8C is a (relative) address in the .text section of libc-2.18.so
> v=1307279360 = 0x4DEB8000 is the start address of the loaded libc-2.18.so
> l=4294962112 = 0xFFFFEBC0 is the ânegativeâ sec_load_offset, which accommodates for the offset between the .text section in the prelinked library and the .text section in the non-prelinked file with the debug information.
>
> As a result the location 0x4DF00A8C = 0x4DEB8000 + 0x48A8C in the prelinked file is converted into a location 0x4DEFF64C = 0x4DEB8000 + 0x48A8C - 0x1440 in the file with debug information, which can be used .
>
> prelinked: debug information:
> +----------------------+ +----------------------+
> | ... | | ... |
> +----------------------+ +----------------------+
> | .rel.dyn size=0x3c18 | | .rel.dyn size=0x2810 |
> +----------------------+ +----------------------+
> | ... | | ... |
> +----------------------+ +----------------------+
> | .text | | .text |
> | 0x4DF00A8C | -> | 0x4DEFF64C |
> +----------------------+ +----------------------+
Thanks, that is interesting.
But it is also wrong that we use section offsets in user space modules.
The sections really shouldn't play a role, except for kernel modules.
User space modules are mapped into memory according to their segments
(phdrs). Could you show the segments plus section to segment mapping of
the libc-2.18.so and libc-2.18.so.debug files used with eu-readelf -Sl
Thanks,
Mark