[lldb] reject `.debug_arange` sections with nonzero segment size

[ldrumm]

Summary

If a producer emits a nonzero segment size, `lldb` will silently read
incorrect values and crash, or do something worse later, as the tuple
size is expected to be 2, rather than 3.

Neither LLVM, nor GCC produce segmented aranges, but this dangerous case
should still be checked and handled.

[clayborg]

Change looks good, just needs a test. Should be easy to take a simple binary that has a .debug_aranges, and run obj2yaml on it, and tweak the segment size as needed?

[labath]

In D75925#1915693, @clayborg wrote:

Change looks good, just needs a test. Should be easy to take a simple binary that has a .debug_aranges, and run obj2yaml on it, and tweak the segment size as needed?

In this case I think the cleanest solution would be to write a c++ unit test: create a simple debug_aranges header (just hardcode bytes, nothing fancy), pass it to DWARFDebugArangesSet::extract, and check the result.

[ldrumm]

I found similar unittests for other DWARF entries which allow me to check more about the parser state, so I went with Pavel's suggestion for the testcase

[clayborg]

lgtm once all formatting issues are taken care of. Pavel?

[labath]

Looks good, just run clang-format before committing.

lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugArangeSet.cpp

   // 1 - the version looks good
   // 2 - the address byte size looks plausible
   // 3 - the length seems to make sense
-  // size looks plausible
+  // 4 - size looks plausible
+  // 5 - the arange tuples do not contain a segment field
   if (m_header.version < 2 || m_header.version > 5)
     return llvm::make_error<llvm::object::GenericBinaryError>(
         "Invalid arange header version");

     return llvm::make_error<llvm::object::GenericBinaryError>(
         "Invalid arange header length");
 
+  if (m_header.seg_size)
+    return llvm::make_error<llvm::object::GenericBinaryError>(
+        "segmented arange entries are not supported");
+
   // The first tuple following the header in each set begins at an offset
   // that is a multiple of the size of a single tuple (that is, twice the
   // size of an address). The header is padded, if necessary, to the