Re: [RFA 2/4] dwarf2_physname

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Daniel" == Daniel Jacobowitz <dan@codesourcery.com> writes:

Daniel> I don't doubt that what you've got is correctly identifying and
Daniel> handling GCC's output.  But it does so by pattern matching on what GCC
Daniel> currently emits, not by using tests that are sound according to the
Daniel> standard.  So with some future GCC, or some other non-GCC compiler,
Daniel> it will probably fall down.

Daniel> I don't believe that most of GCC's uses of DW_AT_specification are
Daniel> required by the standard.  And I don't think they're the only valid
Daniel> uses of DW_AT_specification.  So keying off whether that attribute is
Daniel> present is too 'fuzzy' for me.

I want to tie this back to the original code to see if I understand what
part you are concerned about.

>> +    case DW_TAG_variable:
>> +      {
>> +	struct attribute *attr;
>> +	attr = dwarf2_attr (die, DW_AT_specification, cu);
>> +	if (attr)
>> +	  return 1;

Based on the above I am guessing it is the early return here?

That is the only thing I could think of, because AFAICT this code
generally respects what DWARF says.  My understanding is that there are
2 cases.

1. If the variable is declared in the namespace scope, but defined
outside, then a second defining DIE is emitted that refers to the
declaration DIE using DW_AT_specification.  In this case the declaration
DIE's namespace is used.

... The code above seems to cheat a tiny bit because it unconditionally
returns 1 in this case, whereas it should perhaps recurse.

2. If the variable is defined in the namespace scope, then no
DW_AT_specification exists, and we use the DIE's parentage.  The code
gets this right.

Daniel> I'm asking for you to either convince me that my assumptions in the
Daniel> previous paragraph are incorrect, or to find some way that the
Daniel> standard will support to answer the same query about the properties of
Daniel> the DW_TAG_variable DIE.  For instance, should we find the DIE's
Daniel> logical location the same way determine_prefix does (parent, or
Daniel> specification's parent) and then draw some conclusion based on
Daniel> the type of the logical parent?

>From what I can tell, die_needs_namespace is consistent with
determine_prefix, with the caveat that it is is an approximation, due to
the lack of recursion.  It is more like "die_may_need_namespace".

I'm still not understanding what problem you see, but I would like to.

Tom