[ 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
> 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.
>> 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 *>,
>> 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
>> lldb-dev mailing list
> lldb-dev mailing list
lldb-dev mailing list