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

[Jim Ingham via lldb-commits]

gdb's expression parser went out of it's way to allow you to type as little as possible, and to do things that made no sense in the current context (use variables and types in expressions that aren't actually visible in the current context, etc).  People's workflows came to really depend on these features, and the whole system grew up to support that.  There's a lot of complexity in lldb to support this kind of investigation, but I don't think we can do without it w/o facing a riot.  It's a bit of a "give a mouse a cookie" type situation.

Jim


> On Oct 25, 2018, at 12:09 PM, Zachary Turner <zturner at google.com> wrote:
> 
> 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
>