Re: Prelinking on ARM with Debug Link

[Mark Wielaard <mjw at redhat dot com>]

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