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

[Mark Wielaard <mjw at redhat dot com>]

Hi,

On Mon, 2013-02-04 at 22:34 -0800, agentzh wrote:
> The script used to work perfectly fine for many months (with kernel
> 3.5.x and 3.6.x), but after I upgraded my Linux kernel from 3.6.x to
> 3.7.3-101 via the Fedora official updates, I started getting this
> error:
> 
>     semantic error: not accessible at this address [man error::dwarf]
> (0xffffffff811a4260, dieoffset: 0x1584359): identifier '$pathname' at
> /opt/systemtap/share/systemtap/tapset/linux/syscalls2.stp:3233:30
>             source: 	argstr = user_string_quoted($pathname)
>                 	                            ^

I believe Fedora uses GCC 4.7 and compiles in support for ftrace. That
combination seems to trigger the following GCC bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54793

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?