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: Disappearing return value


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


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