Prelinking on ARM with Debug Link

[Torsten Polle]

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