Disappearing return value

Disappearing return value

[Mike Mason]

I'm trying to probe the following function:

static int nfs_check_flags(int flags)
{
        if ((flags & (O_APPEND | O_DIRECT)) == (O_APPEND | O_DIRECT))
                return -EINVAL;

        return 0;
}

with this script:

probe kernel.function("nfs_check_flags").return ?,
      module("nfs").function("nfs_check_flags").return ?
{
        ret = $return
}

and seeing these errors:

Pass 1: parsed user script and 37 library script(s) in 210usr/10sys/222real ms.
probe nfs_check_flags@?:-1 module=nfs reloc=.text section=.text pc=0x5ef19e0
semantic error: function has no return value: identifier '$return' at nfs2.stp:4:8
semantic error: probe_1060 with unresolved type: identifier 'ret' at nfs2.stp:4:2
Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0 global(s) in 250usr/100sys/348real ms.
Pass 2: analysis failed.  Try again with more '-v' (verbose) options.

nfs_check_flags() looks like a candidate for inlining during optimization, but then I'd expect an error indicating no return probe could be set.  Is this a known problem?

Mike

RE: Disappearing return value

[Stone, Joshua I]

Mike Mason wrote:
> nfs_check_flags() looks like a candidate for inlining during
> optimization, but then I'd expect an error indicating no return probe
> could be set.  Is this a known problem?

I confirmed this on two of my machines, one RHEL5 (2.6.18-8.1.1.el5
i686) and one F7 (2.6.22.5-76.fc7 x86_64).

A function pointer to nfs_check_flags is saved in nfs_file_operations,
so it can't be completely inlined.  I suppose that it could still be
inlined at the call in nfs_file_open, but turning on more verbose output
doesn't seem to indicate that.

parsed 'nfs_check_flags' -> func 'nfs_check_flags'
pattern 'nfs' matches module 'nfs'
focused on module 'nfs = [0x1d52174-0x1d7ebc1, bias 0x0] file
/lib/modules/2.6.18-8.1.1.el5/kernel/fs/nfs/nfs.ko ELF machine i?86
(code 3)
pattern 'nfs_check_flags' matches function 'nfs_check_flags'
selected function nfs_check_flags
probe nfs_check_flags@?:-1 module=nfs reloc=.text section=.text
pc=0x1d56258
literal_stmt_for_return: finding return value for
nfs_check_flags(fs/nfs/file.c)
dwarf_builder releasing dwflpp
semantic error: function has no return value: identifier '$return' at
<input>:1:66

Bizarre...

Josh

RE: Disappearing return value

[Roland McGrath]

The proximate cause of this is a bug in the elfutils backend libraries
that dwfl_module_return_value_location gets to.  I've fixed it in
upstream elfutils.  The only bug there is in dealing with the indirect
attributes in DIEs for inlines.  At first blush it seems this should
never come up, since an inlined function doesn't have a real ABI return
whose value you can examine, or a frame in which to insert a return
probe.  But, what DWARF calls a concrete out-of-line definition of an
inline function is when the function was inlined some places but not
all.  Here the DWARF data is structured with indirections through
abstract_origin as in the inlined_subroutine DIE for an inlined case,
but on a subprogram DIE that describes what is in the compiled code
just a normal static function definition.

nfs_check_flags is such a case.  It is a simple static function, and so
was implicitly inlined in nfs_file_open.  But it's also used as a
function pointer stored in nfs_file_operations, and so has a proper
function definition as well.

The translator probably ought to be noticing this case and treating it
differently.  It's possible to have a return probe on the real
function, but there is also the inlined instance of the same function,
and you can't have a return probe there.  So silently probing the
uninlined return case and skipping the other one might be surprising to
the user.

Why I drop the $return reference from the script so that bug is no
longer tickled it emits what looks to me like one probe with a PC.


Thanks,
Roland