This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: dwarflint --stats
- From: Roland McGrath <roland at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Fri, 17 Sep 2010 16:33:51 -0700
- Subject: Re: dwarflint --stats
> 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