This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
RE: Disappearing return value
- From: "Stone, Joshua I" <joshua dot i dot stone at intel dot com>
- To: "Mike Mason" <mmlnx at us dot ibm dot com>, "systemTAP" <systemtap at sources dot redhat dot com>
- Date: Wed, 26 Sep 2007 17:42:07 -0700
- Subject: RE: Disappearing return value
- References: <46FAE35B.10604@us.ibm.com>
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