Prelinking on ARM with Debug Link

[Torsten Polle]

Hi Mark,

> 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.

> 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.

> 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           |
+----------------------+    +----------------------+

> Cheers,
> Mark

Regards,
Torsten

[1] https://sourceware.org/ml/systemtap/2015-q4/msg00219.html
[2] https://sourceware.org/ml/systemtap/2015-q4/msg00184.html