This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA 2/4] dwarf2_physname
>>>>> "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