DWZ 01/12: Prevent vain lldb::user_id_t 0xffffffff lookups

[jankratochvil]

Summary

I have found LLDB commonly looks up lldb::user_id_t 0xffffffff failing to find its DIE. One would rather expect LLDB_INVALID_UID == 0xffffffffffffffff in such case.

DWARFASTParserClang.cpp:495
492             type_sp.reset(
493                 new Type(die.GetID(), dwarf, type_name_const_str, byte_size, NULL,
494                          DIERef(encoding_uid).GetUID(dwarf), encoding_data_type,
495                          &decl, clang_type, resolve_state));
encoding_uid = (DWARFFormValue) {m_cu = 0x0, m_form = 0, m_value = {value = {uval = 0, sval = 0, cstr = 0x0}, data = 0x0}}
-> DIERef::DIERef(const DWARFFormValue &form_value = {m_cu = 0x0, m_form = 0, m_value = {value = {uval = 0, sval = 0, cstr = 0x0}, data = 0x0}})
-> (DIERef) {cu_offset = 0xffffffff, die_offset = 0xffffffff}
-> lldb::user_id_t DIERef::GetUID(SymbolFileDWARF *dwarf = 0x61d00000b480) const
-> Type::Type(lldb::user_id_t encoding_uid = 0xffffffff)
But 0xffffffff !=
#define LLDB_INVALID_UID UINT64_MAX

No testsuite regressions. OK for check-in?

[clayborg]

The top 32 bits is sometimes used to identify one of many DWARF files that are used to create a cohesive single view of the debug info such as when using DWARF in .o files on Mac, and other things like .dwo support and others. So the top 32 bits do mean something. I don't see any problem with this patch though. You will need to watch all of the buildbots closely after checking this in to make sure it doesn't affect other platforms that use these top 32 bits. Just because the test suite runs clean on your system, doesn't mean it will run smoothly on others. Let me know if you want to take this chance and be on the hook for fixes for other platforms in case things go south.

[jankratochvil]

In D37492#861552, @clayborg wrote:

You will need to watch all of the buildbots closely after checking this in

I have checked there are many buildbots and some are already failing. Is it enough to watch possible regression mails from the buildbots?

be on the hook for fixes for other platforms in case things go south.

I would make some such a follow-up fix but I need access to such system. I can run dwo/dwp on Linux but I do not have any OSX myself.

[clayborg]

This change should be fine. Watch buildbots for changes. If they were clean they should stay clean, if they had some fails, then only those fails should continue failing.

[jankratochvil]

Verified there is no buildbots regression, these buildbots had some real testsuite results for the svn commit 319580:
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/16337
http://lab.llvm.org:8011/builders/lldb-windows7-android/builds/7119
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-android/builds/9147
http://lab.llvm.org:8011/builders/lldb-x86_64-darwin-13.4/builds/7469

lldb/trunk/source/Plugins/SymbolFile/DWARF/DIERef.cpp

lldb::user_id_t DIERef::GetUID(SymbolFileDWARF *dwarf) const {
   //----------------------------------------------------------------------
   // Each SymbolFileDWARF will set its ID to what is expected.
   //
   // SymbolFileDWARF, when used for DWARF with .o files on MacOSX, has the
   // ID set to the compile unit index.
   //
   // SymbolFileDWARFDwo sets the ID to the compile unit offset.
   //----------------------------------------------------------------------
-  if (dwarf)
+  if (dwarf && die_offset != DW_INVALID_OFFSET)
     return dwarf->GetID() | die_offset;
   else
     return LLDB_INVALID_UID;
 }