Re: dwarflint --stats

[Roland McGrath <roland at redhat dot com>]

> This is now on the dwarf branch.  Use like this:
> dwarflint --check=locstats binary

Neat!

> I'm getting a lot of misses from the following areas:
> - artificial variables/parameters (but some of them do have location)

The only ones I can think of to expect are "this" parameters in C++.
Lots of these (pun inevitable) are probably the cases we expect to
be getting DW_OP_GNU_implicit_pointer and were unrepresentable before.

I think this is exactly what Jakub was interested in seeing, i.e. to do a
current gcc trunk bootstrap build, and see the stats for e.g. that build's
libstdc++.so vs the build with the previous compiler.

> - descendants of DIEs that have DW_AT_inlined == "inlined" or 
> "declared_inlined" (but many of them do have location)

In the abstract instance trees, it's normal to have all the parameters and
variables without a location.  I would expect only the statics to have a
location in an abstract instance tree.  What's really interesting is to
how many of the corresponding DIEs in the concrete instance tree do have
location or const_value.

> - descendants of DIEs that are DW_TAG_inlined_subroutine (but there's so 
> much of them that that's no wonder.  Ignoring those cuts off about 90% 
> of variable/parameter DIEs)

These are the interesting ones, the concrete instance trees.  When one (or
more) of these has an abstract_origin pointing to a given abstract instance
tree DIE, then it's only really interesting what proportion of the concrete
instances have location/const_value.  For a variable/formal_parameter in
the abstract instance that has its own location/const_value, the
corresponding concrete instance entry might just be omitted (should be,
probably, by the spec).

> I used c++/dwarf header for getting the scope.  Does that/will that take 
> into account the DW_AT_start_scope adjustments, or is that something 
> that the client should take care of themselves?

I'm not sure which interfaces C++ you are referring to exactly, but
there is no libdw code that makes use of DW_AT_start_scope implicitly.
This certainly seems like something it could be worthwhile to have
library help for.

> Currently it emits a table like this:

That looks pretty fancy!  
I'll leave it to Jakub to say what the most useful kinds of reports are.

Great work!


Thanks,
Roland