This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [BUG] syscall.unlink no longer works after upgrading kernel to 3.7.3
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.