[llvm-dwarfdump] --gdb-index: fix uninitialized TuListOffset

[MaskRay]

Summary

Unfortunately I can't make a test because I don't know how to produce a
non-empty types CU list.

[ikudrin]

I don't know a way to create that list, too. lld definitely does not create it. Maybe, gold can help?

Anyway, for this patch, expanding existing dwarfdump-dump-gdbindex.test should be enough.

[MaskRay]

In D63537#1549839, @ikudrin wrote:

I don't know a way to create that list, too. lld definitely does not create it. Maybe, gold can help?

Anyway, for this patch, expanding existing dwarfdump-dump-gdbindex.test should be enough.

lld definitely does not create .gdb_index:

// Write the address area.
Hdr->CuTypesOff = Buf - Start;
Hdr->AddressAreaOff = Buf - Start;

but I can't get gold --gdb-index to produce it, either, even if I compile a not-so-trivial program with gcc.

[ikudrin]

Yes, I saw the same lines in lld.

At least, we can check that we report the correct value for the offset, even if the list is empty. dwarfdump-dump-gdbindex.test already has such input binary, so you only need to add some CHECK: lines.

[MaskRay]

Update test/DebugInfo/dwarfdump-dump-gdbindex.test

[ikudrin]

LGTM. Thanks!

[dblaikie]

llvm/trunk/lib/DebugInfo/DWARF/DWARFGdbIndex.cpp

141–148 ↗

(On Diff #205574)

Is this loop still untested (since all the test cases have TuListSize of zero - so the body of this loop could be incorrect & no test would diagnose it? (eg: if you put "assert(false)" in the loop, does it fire?)

For test cases of this feature, you could either construct one by hand writing assembly - or it's possible (& probably better to check the format agrees with gdb) by using gdb to generate the index: https://www-zeuthen.desy.de/unix/unixguide/infohtml/gdb/Index-Files.html

[MaskRay]

@dblaikie save gdb-index generates index files of version 8. gold/lld generate version 7, llvm-dwarfdump recognize version 7 but not 8...

mkdir dir
gdb a -batch -q -ex 'save gdb-index dir'
objcopy --add-section .gdb_index=dir/a.gdb-index --set-section-flags .gdb_index=readonly a b

% myllvm-dwarfdump -gdb-index b
b:      file format ELF64-x86-64

.gdb_index contents:

<error parsing>

[dblaikie]

In D63537#1557210, @MaskRay wrote:

@dblaikie save gdb-index generates index files of version 8. gold/lld generate version 7, llvm-dwarfdump recognize version 7 but not 8...

mkdir dir
gdb a -batch -q -ex 'save gdb-index dir'
objcopy --add-section .gdb_index=dir/a.gdb-index --set-section-flags .gdb_index=readonly a b

% myllvm-dwarfdump -gdb-index b
b:      file format ELF64-x86-64

.gdb_index contents:

<error parsing>

Perhaps an older version of GDB would produce the older index?

[MaskRay]

Ping

@dblaikie I'm thinking if we should support gdb index version 8.

This 2013 change bumped the index version from 7 to 8: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=796a7ff8234cfaa8ad1ab884c1c8dafe29b18d42 My take is that the index format doesn't change.

I tried the C example on https://sourceware.org/bugzilla/show_bug.cgi?id=15021 . Unfortunately, the produced .gdb_index from mkdir dir; gdb-8 a -batch -q -ex 'save gdb-index dir'; objcopy --add-section .gdb_index=dir/a.gdb-index --set-section-flags .gdb_index=readonly a b has an abnormal large "number of CU indices":

178|   // The constant pool. CU vectors are stored first, followed by strings.                                 
179|   // The first value is the number of CU indices in the vector. Each subsequent                           
180|   // value is the index and symbol attributes of a CU in the CU list.                                     
181|   for (uint32_t i = 0; i < CuVectorsTotal; ++i) {
182|     ConstantPoolVectors.emplace_back(0, SmallVector<uint32_t, 0>());                                      
183|     auto &Vec = ConstantPoolVectors.back();
184|     Vec.first = Offset - ConstantPoolOffset;
185| 
186|     uint32_t Num = Data.getU32(&Offset);
187|     for (uint32_t j = 0; j < Num; ++j)
188|       Vec.second.push_back(Data.getU32(&Offset));
(gdb) p/x Num
$12 = 0x306f6f66

(gdb_7.4.1-1_amd64.deb from http://snapshot.debian.org/package/gdb/7.4.1-1/ says it uses index version 5)

Older gdb is not easy to build:

% cd /tmp/p/gdb-7.6
% mkdir Release; cd Release; ../configure --disable-binutils --disable-gas --disable-gdb --disable-gold --disable-gprof --disable-ld --disable-werror --enable-gdb CFLAGS=-fpermissive CXXFLAGS=-fpermissive --disable-nls && time make -j all-gdb
../../gdb/amd64-linux-nat.c:485:1: error: conflicting types for ‘ps_get_thread_area’                           
 ps_get_thread_area (const struct ps_prochandle *ph,

[MaskRay]

When an enum is used:

enum foo { foo0 };
int main () { return foo0; }

The built .gdb_index will have non-empty type CU list and have a weirdly encoded Num:

186| uint32_t Num = Data.getU32(&Offset); // Num can be very large
187| for (uint32_t j = 0; j < Num; ++j)
188| Vec.second.push_back(Data.getU32(&Offset));

I don't know what gdb does... D64396 may help the investigation a bit.

lib/DebugInfo/DWARF/DWARFGdbIndex.cpp

bool DWARFGdbIndex::parseImpl(DataExtractor Data) {
   uint32_t Offset = 0;
 
   // Only version 7 is supported at this moment.
   Version = Data.getU32(&Offset);
   if (Version != 7)
     return false;
 
   CuListOffset = Data.getU32(&Offset);
-  uint32_t CuTypesOffset = Data.getU32(&Offset);
+  TuListOffset = Data.getU32(&Offset);
   AddressAreaOffset = Data.getU32(&Offset);
   SymbolTableOffset = Data.getU32(&Offset);
   ConstantPoolOffset = Data.getU32(&Offset);
 
   if (Offset != CuListOffset)
     return false;
 
-  uint32_t CuListSize = (CuTypesOffset - CuListOffset) / 16;
+  uint32_t CuListSize = (TuListOffset - CuListOffset) / 16;
   CuList.reserve(CuListSize);
   for (uint32_t i = 0; i < CuListSize; ++i) {
     uint64_t CuOffset = Data.getU64(&Offset);
     uint64_t CuLength = Data.getU64(&Offset);
     CuList.push_back({CuOffset, CuLength});
   }
 
   // CU Types are no longer needed as DWARF skeleton type units never made it
   // into the standard.
-  uint32_t TuListSize = (AddressAreaOffset - CuTypesOffset) / 24;
+  uint32_t TuListSize = (AddressAreaOffset - TuListOffset) / 24;
   TuList.resize(TuListSize);
   for (uint32_t I = 0; I < TuListSize; ++I) {
     uint64_t CuOffset = Data.getU64(&Offset);
     uint64_t TypeOffset = Data.getU64(&Offset);
     uint64_t Signature = Data.getU64(&Offset);
     TuList[I] = {CuOffset, TypeOffset, Signature};
   }