[Lldb-commits] [PATCH] D53597: Don't type-erase the SymbolContextItem enum

[Zachary Turner via lldb-commits]

Yes, it's an interesting dichotomy how the two formats have evolved.  PDB
was designed with IDEs in mind so it's optimized around exact matches.  For
example, you press a key on a specific line of code.  Nobody ever is
entering commands to do fuzzy lookups based on base names, so this was
never really considered a use case.  And if you go and try to use Windows
command line debuggers, it's indeed slow.

On Thu, Oct 25, 2018 at 11:51 AM Jim Ingham <jingham at apple.com> wrote:

> I am pretty sure the has is computed from the name string.  And BTW,
> having the base name in the quick lookup tables (either with or alongside
> the full name) is a really good thing.  People using the debugger really
> don't want to type out fully qualified names as a general rule.  So you
> have to quickly support incomplete name searches, and the best way to do
> that is grab the base name, and start matching up to where the input
> stopped specifying the name.  So if you're only going to have one entry per
> type, having the base name be the quick lookup is more flexible, though it
> does have the cost that fully specified names are slower to lookup.  But
> the slowness is not O(number of symbols) which would be horrible but
> O(number of symbols with this base name).  That can get bad for all the
> commonly used type names in C++ templates - the STL seems to produce
> boatloads of types of the same base name.  But still isn't that bad.
>
> Jim
>
>
> > On Oct 25, 2018, at 11:40 AM, Zachary Turner <zturner at google.com> wrote:
> >
> > I guess the question is, How is that hash and the bucket computed?  If
> it's based on the full name, then you should be able to get fast exact
> lookup.  If it's based on the based name, then it will indeed be slow.
> >
> > On Thu, Oct 25, 2018 at 11:33 AM Jim Ingham via Phabricator via
> lldb-commits <lldb-commits at lists.llvm.org> wrote:
> > jingham added a comment.
> >
> > Ah, right...  Too many patches (a good problem!)
> >
> > The standard as I read it says that the name entry points into the
> general string table, but doesn't specify which entry it points to.
> However, the current DWARF debug_info doesn't ever emit a string for the
> fully qualified name, so you would have to construct it specially to have
> an exact name to refer to.  I also couldn't see anything that said
> specifically whether the DW_AT_name for a type has to be the full name or a
> base name, it just says:
> >
> > If a name has been given to the structure, union, or class in the source
> program, then the corresponding structure type, union type, or class type
> entry has a DW_AT_name attribute whose value is a null-terminated string
> containing the type name.
> >
> > But it would bloat the name tables to use the full name, and since you
> can reconstruct it from the context it's not needed...  So I've only seen
> base names in the name entry for types in the debug_info.
> >
> > Anyway, current clang for -gdwarf-5 produces:
> >
> >   Bucket 1 [
> >     Name 2 {
> >       Hash: 0xB887389
> >       String: 0x000000c3 "Foo"
> >       Entry @ 0x92 {
> >         Abbrev: 0x39
> >         Tag: DW_TAG_namespace
> >         DW_IDX_die_offset: 0x0000004c
> >       }
> >     }
> >   ]
> >   Bucket 2 [
> >     Name 3 {
> >       Hash: 0xB8860BA
> >       String: 0x000000c7 "Bar"
> >       Entry @ 0x9b {
> >         Abbrev: 0x13
> >         Tag: DW_TAG_structure_type
> >         DW_IDX_die_offset: 0x0000004e
> >       }
> >     }
> >     Name 4 {
> >       Hash: 0x7C9A7F6A
> >       String: 0x000000b5 "main"
> >       Entry @ 0xa4 {
> >         Abbrev: 0x2E
> >         Tag: DW_TAG_subprogram
> >         DW_IDX_die_offset: 0x00000026
> >       }
> >     }
> >
> > For:
> >
> > namespace Foo
> > {
> >
> >   struct Bar
> >   {
> >     int First;
> >   };
> >
> > }
> >
> > int
> > main()
> > {
> >
> >   Foo::Bar mine = {10};
> >   return mine.First;
> >
> > }
> >
> > Jim
> >
> >
> > https://reviews.llvm.org/D53597
> >
> >
> >
> > _______________________________________________
> > lldb-commits mailing list
> > lldb-commits at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20181025/8acad53e/attachment.html>