If it's dead code, that certainly simplifies things! I've sent a patch for
review to remove the unused, untested code.
On Mon, Feb 12, 2018 at 1:52 AM, Pavel Labath <lab...@google.com> wrote:
> [ Clang's emission of pubnames/pubtypes is controlled by the "debugger
> tuning" parameter. With -glldb they don't get emitted, with -ggdb,
> they do. (-glldb is default on mac, -ggdb elsewhere). In dwarf5 these
> sections have been dropped in favour of the new .debug_names section.
> On 10 February 2018 at 02:25, Jim Ingham via lldb-dev
> <email@example.com> wrote:
> > A quick glance indicates that this is all dead code. I can't see
> anything that actually instantiates either of the pubnames classes.
> > The DWARF pubnames tables were a previous attempt at producing DWARF
> indexes, but they didn't contain enough information to actually forstall
> deep dives into the DWARF, so they weren't actually useful. clang doesn't
> emit them on macOS for sure, does it emit them on linux? They are
> superseded by the new DWARF 5 accelerator tables, and I couldn't find any
> reference to pubnames in the DWARF 5 draft standard.
> > We should check with Greg about this, but I don't think we're ever
> likely to get any use out of DWARF pubnames tables. We should just delete
> this code.
> > Jim
> >> On Feb 9, 2018, at 4:35 PM, Adrian McCarthy via lldb-dev <
> firstname.lastname@example.org> wrote:
> >> DWARFDebugPubnamesSet.h has a type definition like this:
> >> typedef std::unordered_multimap<const char *, uint32_t,
> >> std::hash<const char *>,
> >> CStringEqualBinaryPredicate>
> >> cstr_to_index_mmap;
> >> In particular, note that the hasher will hash the pointer rather than
> the string it points to.
> >> It looks like this mostly works because the map is built once from
> string pointers that don't appear to be changed during the lifetime of the
> multimap. That's fragile, and I'm not sure it's really working in all
> cases. For example, there could be two different pointers to identical
> strings--since this is a multimap rather than a map, I assume we'd want
> those values merged under the same key, but since the pointers are
> distinct, they won't be.
> >> I'd like to change the key to a std::string or a StringRef for
> correctness and robustness, but that'll likely be a tad slower because
> hashing variable-length strings is more work than hashing fixed-length
> pointers. (I don't think it'll change comparisons much, since the
> comparator is checking the strings.)
> >> Objections or better suggestions?
> >> It's also hard for me to test, as most of the LLDB DWARF tests are
> still broken on Windows because the inferiors are generated with CodeView
> rather than DWARF. I'm working on that, but it'll take changes to the
> lld-link driver.
> >> Adrian.
> >> _______________________________________________
> >> lldb-dev mailing list
> >> email@example.com
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> > _______________________________________________
> > lldb-dev mailing list
> > firstname.lastname@example.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
lldb-dev mailing list