Re: How do I trap the return of a function in a user space process?

[Mark Wielaard <mjw at redhat dot com>]

On Mon, Sep 09, 2013 at 08:23:11AM -0400, Martin Martin wrote:
> Here's a simple one.  If you remove the namespace, stap -l shows fun,
> but as below, it doesn't:
> 
> namespace yummy {
> class Foo {
>     int fun();
> };
> 
> int Foo::fun() { return 23; }
> }
> 
> 
> int main()
> {
> }
> 
> A quick google search shows Clang doesn't pass the GDB 7.5 test suite,
> so it seems there are known errors with DWARF generation, but
> presumably something this basic should work?

The problem is that clang generates both the foo declaration TAG and
the actual foo subprogram TAG under the namespace and class_type TAG.
That isn't technically invalid DWARF, but it is somewhat cumbersome
for a DWARF consumer because it mixes the type entries and the code
entries hierarchy. That makes it much harder for the DWARF consumer
to find the actual code entry TAGs.

stap (dwflcpp.cxx) uses elfutils libdw dwarf_funcs which finds all
subprograms for a DIE tree that are direct children of the root CU die.
dwarf_funcs expects all functions of a compile unit to be represented by 
subprogram DIEs that are direct children of the compile unit.

We could support the DWARF that clang outputs in this case, but that
does mean a somewhat expensive walk of the whole DIE tree. We might get
away with only looking for (nested) DW_TAG_namespace, DW_TAG_class_type
and DW_TAG_structure_type DIEs. But if so we probably also need to update
dwarf_getfuncs to handle imported_units. Which currently aren't an
issue since dwz will never place the top-level DW_TAG_subprograms
in a partial unit, but might do so when DW_TAG_subprograms are nested
in the type hierarchy like here.

Cheers,

Mark