Hi,
a future FEAT, possibly to file it in some BZ?
http://dwarf.freestandards.org/Dwarf3.pdf 4.1.-4. (page 71/267) says about DW_AT_location: # In a variable entry representing the definition of a variable (that is, with # no DW_AT_declaration attribute) if no location attribute is present, or if # the location attribute is present but has a null description (as described # in Section 2.6), the variable is assumed to exist in the source code but not # in the executable program (but see number 10, below).
dwarflint could warn on existing zero-length DW_FORM_block* DW_AT_location for DW_AT_variable with neither DW_AT_declaration nor DW_TAG_const_value. This should mean the same as missing DW_AT_location - which has smaller DWARF code.
(GDB has a bug - it behaves differently to it as it _ignores_ variable with DW_AT_location missing. It should consider it as _optimized-out_ as in the case of the empty DW_FORM_block* of DW_AT_location).
Assuming for attributes like DW_AT_upper_bound the difference makes sense - unbound array (missing DW_AT_upper_bound) vs. optimized-out bound of the array (DW_AT_upper_bound with empty DW_FORM_block*).
Regards, Jan
a future FEAT, possibly to file it in some BZ?
We are not using BZ for dwarf branch development tasks, just this mailing list and the wiki. This sort of check on producer high-level semantics is something we vaguely plan for the future, but is not on our critical path for development.
It would be great to collect these ideas on the DwarfLint wiki page or another new wiki page for planning this particular sort of check.
dwarflint could warn on existing zero-length DW_FORM_block* DW_AT_location for DW_AT_variable with neither DW_AT_declaration nor DW_TAG_const_value. This should mean the same as missing DW_AT_location - which has smaller DWARF code.
I had actually contemplated the converse check. That is, call questionable a variable/formal_parameter DIE with no location attrs (nor alternatives like const_value). I thought of this because the buggy/poor GCC generation for e.g. inlines' parameters' locations produced no attrs at all and looks like the compiler just forgot they could have them. In contrast, an attr with an empty expression is a clear and explicit sign that the compiler is saying, "I know about it, but it's optimized out."
It's true that by the spec missing and empty mean the same. The space cost of the attr with empty expr is about a byte (modulo the abbrev) and so seemed negligible to me. OTOH, they could add up and I recognize that. Your idea may well be a better idea. For these kinds of checks I think the deciding criterion is what is in practice most helpful in diagnosing the cases where the compiler is not doing what it should.
Thanks, Roland
On Thu, 05 Mar 2009 22:17:57 +0100, Roland McGrath wrote:
It would be great to collect these ideas on the DwarfLint wiki page
done.
I had actually contemplated the converse check. That is, call questionable a variable/formal_parameter DIE with no location attrs (nor alternatives like const_value). I thought of this because the buggy/poor GCC generation for e.g. inlines' parameters' locations produced no attrs at all and looks like the compiler just forgot they could have them.
From the practical standpoint I agree (as it is now missing in PR debug/39372).
Thanks, Jan
elfutils-devel@lists.fedorahosted.org
-
Jan Kratochvil -
Roland McGrath