Dwarf scopes after compression

[Josh Stone <jistone at redhat dot com>]

I started this conversation with Roland on #systemtap.  At first I was
asking about ways that I might cache some of the DIE traversals, but I
think the issues we were talking about are actually orthogonal to caching.

The point we got to is that the planned dwarf compression techniques
will graft common DIE subtrees together, so there may be multiple paths
from a CUDIE to some other DIE.  When you call dwarf_getscopes[_die],
the traversal stops at the first complete chain it finds.  The
discussion then is how to decide whether a particular graft would make
an incompatible change in the resolved scopes.

For example, suppose we have A::foo() and B::foo(), and some subtrees in
foo are identical, so we want to omit the B::foo subtree and just link
it to A::foo.  Is this consolidation ok?  The answer probably depends on
what the dwarf is used for.

Currently in systemtap, we use dwarf_getscopes to get the lexical
hierarchy for resolving variables, and dwarf_getscopes_die to get the
physical hierarchy for resolving the frame base.  As long as A:: and B::
really have the same variable scopes, I think it should be fine to merge
them.

I want to add systemtap support for matching and showing the
fully-scoped name of a function.  It seems the way to do this is to call
getscopes_die on the specification, and walk up the result to get
namespace::class::etc.  I think the compression won't have combined
anything in this path, since they'll have different decl_file/line, etc.

Now that I've written this out, I'm actually not seeing anything that
compression is likely to break for us.  Either I'm forgetting something
else that stap does or could do, or I was worrying for nothing.

Or perhaps Roland has some really bizarre cases where things might be
merged?  He said that some of it depends on what assumptions we're
making as users, so maybe I need my assumptions pointed out to me... :)

Thanks,

Josh