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

Jim Ingham via lldb-commits lldb-commits at lists.llvm.org
Thu Oct 25 11:51:12 PDT 2018


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



More information about the lldb-commits mailing list