Re: [Dwarf-Discuss] debug_names - what should go in ?
> On Apr 11, 2018, at 4:45 AM, Pavel Labath via Dwarf-Discuss > wrote: > > Thank you all for the feedback. There seems to be general consensus that > enumerators should be present in the name index. > > However, I am starting to have second thoughts about imported declarations. > While the entities they declare are (can be) global in the sense that they > are not (don't have to be) inside a function, they are also *local* in the > sense that they are valid only inside one compilation unit -- just because > one .cpp file does a "namespace X = foo:bar", it does not mean that everyone > can refer to these entities that way. > > The example of "using namespace a" in Greg's very informative response made > my realize I may be going about this the wrong way. If I were to represent > every name imported by "using namespace std", I would have to create > thousands of entries. That seems like a bad idea, and totally unnecessary, as > lldb seems to handle the "using namspace" case just fine without this. > > Greg, could you elaborate on how this works? Do we just parse the compilation > unit we are stopped in and pick out the "using" declarations from there? If > that is the case, then why doesn't the namespace alias declaration work as > well ? The expression 2 from my example fails in lldb. Could it be that it's > just an lldb bug, and that we don't need to change anything in the > accelerator tables? Since we use clang as our expression parser, we get asked about each name as the expression parser runs into it. So for namesp2::var we would first get asked about "namesp2" and we probably tried to look that up in our tables and found nothing. I believe our expression parser does try to determine using directives using the debug info, but I would defer to the expression parsing folks as I remember hearing about that, but don't remember what was done about it. So it is probably failing due to "namesp2" not being the accelerator tables that causes it to fail. I am pretty sure we don't add imported declarations to our tables. > > > ___ > Dwarf-Discuss mailing list > Dwarf-Discuss@lists.dwarfstd.org > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] debug_names - what should go in ?
Thank you all for the feedback. There seems to be general consensus that enumerators should be present in the name index. However, I am starting to have second thoughts about imported declarations. While the entities they declare are (can be) global in the sense that they are not (don't have to be) inside a function, they are also *local* in the sense that they are valid only inside one compilation unit -- just because one .cpp file does a "namespace X = foo:bar", it does not mean that everyone can refer to these entities that way. The example of "using namespace a" in Greg's very informative response made my realize I may be going about this the wrong way. If I were to represent every name imported by "using namespace std", I would have to create thousands of entries. That seems like a bad idea, and totally unnecessary, as lldb seems to handle the "using namspace" case just fine without this. Greg, could you elaborate on how this works? Do we just parse the compilation unit we are stopped in and pick out the "using" declarations from there? If that is the case, then why doesn't the namespace alias declaration work as well ? The expression 2 from my example fails in lldb. Could it be that it's just an lldb bug, and that we don't need to change anything in the accelerator tables? ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] debug_names - what should go in ?
On Tue, Apr 10, 2018 at 12:24 PM, Pavel Labath via Dwarf-Discuss
wrote:
> namespace namesp1 { int var; }
> namespace namesp2 = namesp1; // DW_TAG_imported_declaration
A namespace alias like this should certainly be represented. I'm not
sure about other uses of DW_TAG_imported_declaration.
Jason
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] debug_names - what should go in ?
That's good to know - thanks Jim!
Pavel, for unnamed using directives/declarations - why would you need to
add the name to the index, shouldn't it already be in the index (if the
index contains unqualified names) from its original location/definition?
On Tue, Apr 10, 2018 at 10:44 AM Jim Ingham via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> This is certainly how lldb treats the Apple names and types indexes. If
> present, we don't do any indexing of DWARF, we just use the indexes, and of
> course any local context.
>
> Enums have been a long-standing problem with this approach, the Apple
> indices only mention the enum type, so you can't use them in expressions in
> they way you would type them in code. It would be nice to fix that.
>
> Jim
>
>
> > On Apr 10, 2018, at 10:37 AM, Eric Christopher via Dwarf-Discuss <
> dwarf-discuss@lists.dwarfstd.org> wrote:
> >
> > I have nothing to add to what Paul just said :)
> >
> > This is definitely the intent and what we should do.
> >
> > -eric
> >
> > On Tue, Apr 10, 2018 at 10:26 AM Paul Robinson via Dwarf-Discuss <
> dwarf-discuss@lists.dwarfstd.org> wrote:
> > The intent of the index is given pretty plainly in the non-normative
> text at the bottom of p.137; you should be able to look up any unqualified
> name in the index. If the normative text doesn't accomplish that, we have
> an opportunity to improve the spec. J
> >
> >
> >
> > FWIW here's my take:
> >
> >
> >
> > Enumerations are a bit unusual in that the enumerators are children of
> the enumeration type, but the enumerator names are not qualified by the
> type name (usually—a C++ enum-class should not put enumerators into the
> index, I think). But you need some rule that excludes enumerations that
> are not otherwise "global" (e.g., they are contained in a class or local to
> a function).
> >
> >
> >
> > For imported entities, I'd say if the imported entity would have
> satisfied the criteria for inclusion in the index if it had been "inlined"
> at the point where it was imported, then it ought to be in the index.
> >
> > --paulr
> >
> >
> >
> >
> >
> > From: Dwarf-Discuss [mailto:dwarf-discuss-boun...@lists.dwarfstd.org]
> On Behalf Of David Blaikie via Dwarf-Discuss
> > Sent: Tuesday, April 10, 2018 12:30 PM
> > To: Pavel Labath
> > Cc: dwarf-discuss@lists.dwarfstd.org
> > Subject: Re: [Dwarf-Discuss] debug_names - what should go in ?
> >
> >
> >
> > Yep - sounds like it to me.
> >
> > I suppose, arguably, one could say that successful name lookups of
> things in the index can be fast, while lookups that fail, or find names not
> in the index may be slow - but that seems unacceptable to me (in many cases
> "slow" would be "prohibitively slow" especially the first time - since it'd
> amount to the non-index case: the consumer having to build its own index
> from scratch)
> >
> > Maybe Adrian or Eric can talk to how the Apple indexes worked in these
> cases.
> >
> >
> >
> > On Tue, Apr 10, 2018 at 9:24 AM Pavel Labath wrote:
> >
> > On Tue, 10 Apr 2018 at 16:44, David Blaikie wrote:
> >
> > I'd say any case where a consumer couldn't actually rely on the table to
> do name resolution would be a bug - or at least something that needs to be
> seriously considered/discussed/figured out how the name table can be used
> in those situations.
> >
> >
> >
> > Agreed.
> >
> >
> >
> > This question can be demonstrated on a simple c++ program
> >
> >
> >
> > namespace namesp1 { int var; }
> >
> > namespace namesp2 = namesp1; // DW_TAG_imported_declaration
> >
> >
> >
> > enum enum_type { enumerator }; // DW_TAG_enumeration_type,
> DW_TAG_enumerator
> >
> >
> >
> > int main() {
> >
> > return namesp2::var + enumerator;
> >
> > }
> >
> >
> >
> >
> >
> > Debugging with gdb (without any indexes), the following 4 expressions
> succeed
> >
> > 1) namesp1::var
> >
> > 2) namesp2::var
> >
> > 3) (enum_type)0
> >
> > 4) enumerator
> >
> >
> >
> > The question is how should an index-aware debugger find the entities
> referenced by expressions 2 and 4 if they are not present in the index?
> >
> >
> >
> > They way I see it -- it can't. Which would be a bug in the spec by your
> definition.
> >
> > ___
> > Dwarf-Discuss mailing list
> > Dwarf-Discuss@lists.dwarfstd.org
> > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
> > ___
> > Dwarf-Discuss mailing list
> > Dwarf-Discuss@lists.dwarfstd.org
> > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
> ___
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] debug_names - what should go in ?
This is certainly how lldb treats the Apple names and types indexes. If
present, we don't do any indexing of DWARF, we just use the indexes, and of
course any local context.
Enums have been a long-standing problem with this approach, the Apple indices
only mention the enum type, so you can't use them in expressions in they way
you would type them in code. It would be nice to fix that.
Jim
> On Apr 10, 2018, at 10:37 AM, Eric Christopher via Dwarf-Discuss
> wrote:
>
> I have nothing to add to what Paul just said :)
>
> This is definitely the intent and what we should do.
>
> -eric
>
> On Tue, Apr 10, 2018 at 10:26 AM Paul Robinson via Dwarf-Discuss
> wrote:
> The intent of the index is given pretty plainly in the non-normative text at
> the bottom of p.137; you should be able to look up any unqualified name in
> the index. If the normative text doesn't accomplish that, we have an
> opportunity to improve the spec. J
>
>
>
> FWIW here's my take:
>
>
>
> Enumerations are a bit unusual in that the enumerators are children of the
> enumeration type, but the enumerator names are not qualified by the type name
> (usually—a C++ enum-class should not put enumerators into the index, I
> think). But you need some rule that excludes enumerations that are not
> otherwise "global" (e.g., they are contained in a class or local to a
> function).
>
>
>
> For imported entities, I'd say if the imported entity would have satisfied
> the criteria for inclusion in the index if it had been "inlined" at the point
> where it was imported, then it ought to be in the index.
>
> --paulr
>
>
>
>
>
> From: Dwarf-Discuss [mailto:dwarf-discuss-boun...@lists.dwarfstd.org] On
> Behalf Of David Blaikie via Dwarf-Discuss
> Sent: Tuesday, April 10, 2018 12:30 PM
> To: Pavel Labath
> Cc: dwarf-discuss@lists.dwarfstd.org
> Subject: Re: [Dwarf-Discuss] debug_names - what should go in ?
>
>
>
> Yep - sounds like it to me.
>
> I suppose, arguably, one could say that successful name lookups of things in
> the index can be fast, while lookups that fail, or find names not in the
> index may be slow - but that seems unacceptable to me (in many cases "slow"
> would be "prohibitively slow" especially the first time - since it'd amount
> to the non-index case: the consumer having to build its own index from
> scratch)
>
> Maybe Adrian or Eric can talk to how the Apple indexes worked in these cases.
>
>
>
> On Tue, Apr 10, 2018 at 9:24 AM Pavel Labath wrote:
>
> On Tue, 10 Apr 2018 at 16:44, David Blaikie wrote:
>
> I'd say any case where a consumer couldn't actually rely on the table to do
> name resolution would be a bug - or at least something that needs to be
> seriously considered/discussed/figured out how the name table can be used in
> those situations.
>
>
>
> Agreed.
>
>
>
> This question can be demonstrated on a simple c++ program
>
>
>
> namespace namesp1 { int var; }
>
> namespace namesp2 = namesp1; // DW_TAG_imported_declaration
>
>
>
> enum enum_type { enumerator }; // DW_TAG_enumeration_type, DW_TAG_enumerator
>
>
>
> int main() {
>
> return namesp2::var + enumerator;
>
> }
>
>
>
>
>
> Debugging with gdb (without any indexes), the following 4 expressions succeed
>
> 1) namesp1::var
>
> 2) namesp2::var
>
> 3) (enum_type)0
>
> 4) enumerator
>
>
>
> The question is how should an index-aware debugger find the entities
> referenced by expressions 2 and 4 if they are not present in the index?
>
>
>
> They way I see it -- it can't. Which would be a bug in the spec by your
> definition.
>
> ___
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
> ___
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] debug_names - what should go in ?
I have nothing to add to what Paul just said :)
This is definitely the intent and what we should do.
-eric
On Tue, Apr 10, 2018 at 10:26 AM Paul Robinson via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> The intent of the index is given pretty plainly in the non-normative text
> at the bottom of p.137; you should be able to look up any unqualified name
> in the index. If the normative text doesn't accomplish that, we have an
> opportunity to improve the spec. J
>
>
>
> FWIW here's my take:
>
>
>
> Enumerations are a bit unusual in that the enumerators are children of the
> enumeration type, but the enumerator names are not qualified by the type
> name (usually—a C++ enum-class should not put enumerators into the index, I
> think). But you need some rule that excludes enumerations that are not
> otherwise "global" (e.g., they are contained in a class or local to a
> function).
>
>
>
> For imported entities, I'd say if the imported entity would have satisfied
> the criteria for inclusion in the index if it had been "inlined" at the
> point where it was imported, then it ought to be in the index.
>
> --paulr
>
>
>
>
>
> *From:* Dwarf-Discuss [mailto:dwarf-discuss-boun...@lists.dwarfstd.org] *On
> Behalf Of *David Blaikie via Dwarf-Discuss
> *Sent:* Tuesday, April 10, 2018 12:30 PM
> *To:* Pavel Labath
> *Cc:* dwarf-discuss@lists.dwarfstd.org
> *Subject:* Re: [Dwarf-Discuss] debug_names - what should go in ?
>
>
>
> Yep - sounds like it to me.
>
> I suppose, arguably, one could say that successful name lookups of things
> in the index can be fast, while lookups that fail, or find names not in the
> index may be slow - but that seems unacceptable to me (in many cases "slow"
> would be "prohibitively slow" especially the first time - since it'd amount
> to the non-index case: the consumer having to build its own index from
> scratch)
>
> Maybe Adrian or Eric can talk to how the Apple indexes worked in these
> cases.
>
>
>
> On Tue, Apr 10, 2018 at 9:24 AM Pavel Labath wrote:
>
> On Tue, 10 Apr 2018 at 16:44, David Blaikie wrote:
>
> I'd say any case where a consumer couldn't actually rely on the table to
> do name resolution would be a bug - or at least something that needs to be
> seriously considered/discussed/figured out how the name table can be used
> in those situations.
>
>
>
> Agreed.
>
>
>
> This question can be demonstrated on a simple c++ program
>
>
>
> namespace namesp1 { int var; }
>
> namespace namesp2 = namesp1; // DW_TAG_imported_declaration
>
>
>
> enum enum_type { enumerator }; // DW_TAG_enumeration_type,
> DW_TAG_enumerator
>
>
>
> int main() {
>
> return namesp2::var + enumerator;
>
> }
>
>
>
>
>
> Debugging with gdb (without any indexes), the following 4 expressions
> succeed
>
> 1) namesp1::var
>
> 2) namesp2::var
>
> 3) (enum_type)0
>
> 4) enumerator
>
>
>
> The question is how should an index-aware debugger find the entities
> referenced by expressions 2 and 4 if they are not present in the index?
>
>
>
> They way I see it -- it can't. Which would be a bug in the spec by your
> definition.
>
> ___
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] debug_names - what should go in ?
The intent of the index is given pretty plainly in the non-normative text at
the bottom of p.137; you should be able to look up any unqualified name in the
index. If the normative text doesn't accomplish that, we have an opportunity
to improve the spec. ☺
FWIW here's my take:
Enumerations are a bit unusual in that the enumerators are children of the
enumeration type, but the enumerator names are not qualified by the type name
(usually—a C++ enum-class should not put enumerators into the index, I think).
But you need some rule that excludes enumerations that are not otherwise
"global" (e.g., they are contained in a class or local to a function).
For imported entities, I'd say if the imported entity would have satisfied the
criteria for inclusion in the index if it had been "inlined" at the point where
it was imported, then it ought to be in the index.
--paulr
From: Dwarf-Discuss [mailto:dwarf-discuss-boun...@lists.dwarfstd.org] On Behalf
Of David Blaikie via Dwarf-Discuss
Sent: Tuesday, April 10, 2018 12:30 PM
To: Pavel Labath
Cc: dwarf-discuss@lists.dwarfstd.org
Subject: Re: [Dwarf-Discuss] debug_names - what should go in ?
Yep - sounds like it to me.
I suppose, arguably, one could say that successful name lookups of things in
the index can be fast, while lookups that fail, or find names not in the index
may be slow - but that seems unacceptable to me (in many cases "slow" would be
"prohibitively slow" especially the first time - since it'd amount to the
non-index case: the consumer having to build its own index from scratch)
Maybe Adrian or Eric can talk to how the Apple indexes worked in these cases.
On Tue, Apr 10, 2018 at 9:24 AM Pavel Labath
mailto:lab...@google.com>> wrote:
On Tue, 10 Apr 2018 at 16:44, David Blaikie
mailto:dblai...@gmail.com>> wrote:
I'd say any case where a consumer couldn't actually rely on the table to do
name resolution would be a bug - or at least something that needs to be
seriously considered/discussed/figured out how the name table can be used in
those situations.
Agreed.
This question can be demonstrated on a simple c++ program
namespace namesp1 { int var; }
namespace namesp2 = namesp1; // DW_TAG_imported_declaration
enum enum_type { enumerator }; // DW_TAG_enumeration_type, DW_TAG_enumerator
int main() {
return namesp2::var + enumerator;
}
Debugging with gdb (without any indexes), the following 4 expressions succeed
1) namesp1::var
2) namesp2::var
3) (enum_type)0
4) enumerator
The question is how should an index-aware debugger find the entities referenced
by expressions 2 and 4 if they are not present in the index?
They way I see it -- it can't. Which would be a bug in the spec by your
definition.
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] debug_names - what should go in ?
Yep - sounds like it to me.
I suppose, arguably, one could say that successful name lookups of things
in the index can be fast, while lookups that fail, or find names not in the
index may be slow - but that seems unacceptable to me (in many cases "slow"
would be "prohibitively slow" especially the first time - since it'd amount
to the non-index case: the consumer having to build its own index from
scratch)
Maybe Adrian or Eric can talk to how the Apple indexes worked in these
cases.
On Tue, Apr 10, 2018 at 9:24 AM Pavel Labath wrote:
> On Tue, 10 Apr 2018 at 16:44, David Blaikie wrote:
>
>> I'd say any case where a consumer couldn't actually rely on the table to
>> do name resolution would be a bug - or at least something that needs to be
>> seriously considered/discussed/figured out how the name table can be used
>> in those situations.
>>
>
> Agreed.
>
> This question can be demonstrated on a simple c++ program
>
> namespace namesp1 { int var; }
> namespace namesp2 = namesp1; // DW_TAG_imported_declaration
>
> enum enum_type { enumerator }; // DW_TAG_enumeration_type,
> DW_TAG_enumerator
>
> int main() {
> return namesp2::var + enumerator;
> }
>
>
> Debugging with gdb (without any indexes), the following 4 expressions
> succeed
> 1) namesp1::var
> 2) namesp2::var
> 3) (enum_type)0
> 4) enumerator
>
> The question is how should an index-aware debugger find the entities
> referenced by expressions 2 and 4 if they are not present in the index?
>
> They way I see it -- it can't. Which would be a bug in the spec by your
> definition.
>
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] debug_names - what should go in ?
On 04/10/2018 08:33 AM, Pavel Labath via Dwarf-Discuss wrote: I believe it makes sense to include both of these things in the index (including the implicitly-named imported declarations), however I would also like to stick to the specification as much as possible. I know the spec gives implementors freedom to include extra information in the index, but I don't want to do that too much, as that would complicate matters for consumers which need to support multiple producers, some of which may have a stricter implementation of the spec. This is a new feature in DWARF v5 with a newly written description. It's possible that some details may have been overlooked or that the wording in the description doesn't fully or unambiguously describe the feature. If you believe that the two TAGs should be included, do so and let us know the results. Please submit a comment at http://dwarfstd.org/Issues.php which describes the situation and your proposed changes to the standard. -- Michael Eagerea...@eagerm.com 1960 Park Blvd., Palo Alto, CA 94306 ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] debug_names - what should go in ?
On Tue, 10 Apr 2018 at 16:44, David Blaikie wrote:
> I'd say any case where a consumer couldn't actually rely on the table to
> do name resolution would be a bug - or at least something that needs to be
> seriously considered/discussed/figured out how the name table can be used
> in those situations.
>
Agreed.
This question can be demonstrated on a simple c++ program
namespace namesp1 { int var; }
namespace namesp2 = namesp1; // DW_TAG_imported_declaration
enum enum_type { enumerator }; // DW_TAG_enumeration_type, DW_TAG_enumerator
int main() {
return namesp2::var + enumerator;
}
Debugging with gdb (without any indexes), the following 4 expressions
succeed
1) namesp1::var
2) namesp2::var
3) (enum_type)0
4) enumerator
The question is how should an index-aware debugger find the entities
referenced by expressions 2 and 4 if they are not present in the index?
They way I see it -- it can't. Which would be a bug in the spec by your
definition.
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] debug_names - what should go in ?
I'd say any case where a consumer couldn't actually rely on the table to do name resolution would be a bug - or at least something that needs to be seriously considered/discussed/figured out how the name table can be used in those situations. On Tue, Apr 10, 2018 at 8:33 AM Pavel Labath via Dwarf-Discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > Hello dwarf-discuss, > > over the last couple of months, I have been implementing DWARF v5 > debug_names generation support in llvm. Implementation is not yet fully > finished, but I have reached a point where I can start testing the > generated index for completeness. > > I wrote a tool (based on LLVM's DWARF verifier) which goes through the > generated debug info and compares it to the contents of the name index. > Right now it takes any debug info entry with a DW_AT_name, applies the > exclusions listed in section 6.1.1.1 of the specification and then reports > if the entry is not present in the index. > > I chose to start with default-to-in policy for the verifier, so I can > evaluate whether any reported discrepancies for possible inclusion or > blacklisting *and* because the wording at the start of the said section was > a bit indeterminate to me -- it uses somewhat vague terms like "subprogram" > and "variable" (***), whereas the rest of the section speaks about specific > tags (DW_TAG_variable, etc.). > > So far, this approach has found a couple of bugs in the generator, some > things which I obviously needed to blacklist (DW_TAG_compilation_unit), and > a couple of questionable reports. Two of the last kind are > DW_TAG_imported_declaration and DW_TAG_enumerator (not > DW_TAG_enumeration_type). > > Both of these define globally visible entities and so if they were not > present, a debugger relying only on the name index would fail to find the > imported enitity or the enumerator even though they should be visible by > the standard scope rules. And yet, both of these are clearly *not* a "named > subprogram, label, variable, type, or namespace". The extra complication > for DW_TAG_imported_declaration is that it can define a named entity even > when it does not have a DW_AT_name attribute (3.2.3: If no name is present, > then the name by which the entity is to be known is the same as the name of > the entity being imported.). > > I believe it makes sense to include both of these things in the index > (including the implicitly-named imported declarations), however I would > also like to stick to the specification as much as possible. I know the > spec gives implementors freedom to include extra information in the index, > but I don't want to do that too much, as that would complicate matters for > consumers which need to support multiple producers, some of which may have > a stricter implementation of the spec. > > So, I wanted to hear your thoughts on this first. How strictly should we > interpret the first paragraph of section 6.1.1.1 (***)? Do you think it > makes sense to add these entries to the name index? > > regards, > pavel labath > > > (***) ""The name index must contain an entry for each debugging information > entry that defines a named subprogram, label, variable, type, or namespace, > subject to the following rules:"" > ___ > Dwarf-Discuss mailing list > Dwarf-Discuss@lists.dwarfstd.org > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org > ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
