Re: [Dwarf-Discuss] debug_names - what should go in ?

[Jason Merrill via Dwarf-Discuss]

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 ?

[Eric Christopher via Dwarf-Discuss]

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 <lab...@google.com> wrote:
>
> On Tue, 10 Apr 2018 at 16:44, David Blaikie <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
>
___
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 ?

[Paul Robinson via Dwarf-Discuss]

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 
<lab...@google.com<mailto:lab...@google.com>> wrote:
On Tue, 10 Apr 2018 at 16:44, David Blaikie 
<dblai...@gmail.com<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 ?

[David Blaikie via Dwarf-Discuss]

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 ?

[Michael Eager via Dwarf-Discuss]

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 ?

[Pavel Labath via Dwarf-Discuss]

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