Re: [BUG] syscall.unlink no longer works after upgrading kernel to 3.7.3

[Zheng Da <zhengda1936 at gmail dot com>]

Hello,

I think I got a very similar error in Ubuntu:
semantic error: not accessible at this address [man error::dwarf]
(0xffffffff81480e80, dieoffset: 0x43d730b): identifier '$sdev' at
:10:6
        source:  if ($sdev->host->host_no == 9 && $sdev->id == 1) {
                     ^
I use Linux v3.8.12, and gcc version is 4.6.3.
Is there any better fix for this problem? I checked the workaround for
perf, but I don't know how to apply it to systemtap.

Thanks,
Da

On Tue, Feb 5, 2013 at 12:29 PM, Josh Stone <jistone@redhat.com> wrote:
> On 02/05/2013 12:57 AM, Mark Wielaard wrote:
>> Perf seems to have a workaround for this issue:
>> https://lkml.org/lkml/2012/10/3/187
>>
>> +     if (fentry && (dwarf_tag(vr_die) == DW_TAG_formal_parameter) &&
>> +         (dwarf_getlocation_addr(&attr, addr, &op, &nops, 1) == 0))
>> +             /*
>> +              * Workaround: GCC -mfentry option generates odd
>> +              * variable location entries which start from a
>> +              * function entry+5, even if it is a formal_parameter.
>> +              * On the other hand, for functions without fentry call
>> +              * (e.g. notrace function), the formal_parameter location
>> +              * starts from the function entry address.
>> +              * Here, if we find a formal_parameter which doesn't
>> +              * start from the function entry, but from function
>> +              * entry+5, it should be a buggy entry.
>> +              * We forcibly get the variable(parameter) location
>> +              * information from entry+5.
>> +              */
>> +             addr += 5;
>>
>> That seems a little crude, but maybe we can do something like that in
>> systemtap too with some special flag?
>
> Aha!  Frank and I were just talking about workarounds for this
> yesterday, and what perf has done here is pretty much what I had in
> mind.  The offset +5 is very arch-specific, of course, for an x86 call.
>
> The other relevant bug is on Fedora's gcc:
> https://bugzilla.redhat.com/show_bug.cgi?id=896741
>
> As soon as the upstream gcc fix is confirmed and backported to Fedora,
> we'll get the kernel folks to spin a new build on it.  In the meantime
> though, I wouldn't mind a heuristic similar to perf's.