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