> 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 _______________________________________________ elfutils-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/elfutils-devel
