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 <ztur...@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 <jing...@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 <ztur...@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@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@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
