This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]