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

David Blaikie dblaikie@gmail.com
Tue Apr 10 16:29:55 GMT 2018


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 <labath at google.com> wrote:

> On Tue, 10 Apr 2018 at 16:44, David Blaikie <dblaikie at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20180410/a0b02cc0/attachment.html>



More information about the Dwarf-discuss mailing list