[llvm-dwarfdump] - Change format for .gdb_index dump.

[grimar]

Summary

During investigation of PR32319,
I found that it is useful to output size when address ranges
are dumped. It is useful when comparing outputs produced
by different linkers.

In that case address ranges can look very different, when they are the same at fact.
Difference comes from different low address because of different address of .text.
Examples below.

Dumped gold output of llc binary (with patch):

Low/High address = [0x120c576, 0x1215df8] (Size: 0x9882), CU id = 0
Low/High address = [0x1215df8, 0x1215e0a] (Size: 0x12), CU id = 0
Low/High address = [0x1215e0a, 0x1215e45] (Size: 0x3b), CU id = 0

Dumped LLD output for the same place (with patch):

Low/High address = [0x31f80f6, 0x3201978] (Size: 0x9882), CU id = 0
Low/High address = [0x3201978, 0x320198a] (Size: 0x12), CU id = 0
Low/High address = [0x320198a, 0x32019c5] (Size: 0x3b), CU id = 0

And without this patch output does not allow to find out that ranges are the same in a fast way:

Low address = 0x120c576, High address = 0x1215df8, CU index = 0
Low address = 0x1215df8, High address = 0x1215e0a, CU index = 0
Low address = 0x1215e0a, High address = 0x1215e45, CU index = 0

vs

Low address = 0x31f80f6, High address = 0x3201978, CU index = 0
Low address = 0x3201978, High address = 0x320198a, CU index = 0
Low address = 0x320198a, High address = 0x32019c5, CU index = 0

[dblaikie]

lib/DebugInfo/DWARF/DWARFGdbIndex.cpp

42 ↗

(On Diff #96570)

While you're here, probably makes sense to fix the range to render as [x, y) rather than [x, y] ? (since it's a half open range, if I recall correctly)

[grimar]

lib/DebugInfo/DWARF/DWARFGdbIndex.cpp

42 ↗

(On Diff #96570)

I am not sure I understand why it is half open. If I got your idea correctly then probably output would be:

[a, b) (c, d) (e, f) (g, h]

But I do not think it would be correct.
.gdb_index format (https://sourceware.org/gdb/onlinedocs/gdb/Index-Section-Format.html) defines address area as:

The address area. The address area consists of a sequence of address entries. Each address entry has three elements:
The low address. This is a 64-bit little-endian value.
The high address. This is a 64-bit little-endian value. Like DW_AT_high_pc, the value is one byte beyond the end.
The CU index. This is an offset_type value.

So we have set of elements that have begining and end marks. It looks to be set of closed segments/snippets, if I am not missing something, so I think [x, y] is more appropriate then.

I was interested how readelf dumps the .gdb_index for the same file used in testcase.
It was:
readelf --debug-dump=gdb_index dwarfdump-gdbindex-v7.elf-x86-64

Contents of the .gdb_index section:
Version 7

CU table:
[  0] 0x0 - 0x33
[  1] 0x34 - 0x67

TU table:

Address table:
00000000004000e8 00000000004000f3 0
00000000004000f3 00000000004000fe 1

Symbol table:
[489] main: 0 [global, function]
[754] int:
	0 [static, type]
	1 [static, type]
[956] main2: 1 [global, function]

Basing on above I can suggest 2 solutions:

1. Leave [x, y] as is.
2. Change dump output to something that avoids use of []() if that can be confusing, for example to:

Address area offset = 0x38, has 2 entries:
0x4000e8 - 0x4000f3, Size = 0xb, CU id = 0
0x4000f3 - 0x4000fe, Size = 0xb, CU id = 1

What do you think ?

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

 }
 
 void DWARFGdbIndex::dumpAddressArea(raw_ostream &OS) const {
   OS << format("\n  Address area offset = 0x%x, has %" PRId64 " entries:",
                AddressAreaOffset, (uint64_t)AddressArea.size())
      << '\n';
   for (const AddressEntry &Addr : AddressArea)
     OS << format(
-        "    Low address = 0x%llx, High address = 0x%llx, CU index = %d\n",
-        Addr.LowAddress, Addr.HighAddress, Addr.CuIndex);
+        "    Low/High address = [0x%llx, 0x%llx) (Size: 0x%llx), CU id = %d\n",
+        Addr.LowAddress, Addr.HighAddress, Addr.HighAddress - Addr.LowAddress,
+        Addr.CuIndex);
 }
 
 void DWARFGdbIndex::dumpSymbolTable(raw_ostream &OS) const {
   OS << format("\n  Symbol table offset = 0x%x, size = %" PRId64
                ", filled slots:",
                SymbolTableOffset, (uint64_t)SymbolTable.size())
      << '\n';
   uint32_t I = -1;

llvm/trunk/test/DebugInfo/dwarfdump-dump-gdbindex.test

 ; CHECK-LABEL: .gnu_index contents:
 ; CHECK: Version = 7
 
 ; CHECK:      CU list offset = 0x18, has 2 entries:
 ; CHECK-NEXT:   0: Offset = 0x0, Length = 0x34
 ; CHECK-NEXT:   1: Offset = 0x34, Length = 0x34
 
 ; CHECK:      Address area offset = 0x38, has 2 entries:
-; CHECK-NEXT:   Low address = 0x4000e8, High address = 0x4000f3, CU index = 0
-; CHECK-NEXT:   Low address = 0x4000f3, High address = 0x4000fe, CU index = 1
+; CHECK-NEXT:   Low/High address = [0x4000e8, 0x4000f3) (Size: 0xb), CU id = 0
+; CHECK-NEXT:   Low/High address = [0x4000f3, 0x4000fe) (Size: 0xb), CU id = 1
 
 ; CHECK:      Symbol table offset = 0x60, size = 1024, filled slots:
 ; CHECK-NEXT:   489: Name offset = 0x1d, CU vector offset = 0x0
 ; CHECK-NEXT:     String name: main, CU vector index: 0
 ; CHECK-NEXT:   754: Name offset = 0x22, CU vector offset = 0x8
 ; CHECK-NEXT:     String name: int, CU vector index: 1
 ; CHECK-NEXT:   956: Name offset = 0x26, CU vector offset = 0x14
 ; CHECK-NEXT:     String name: main2, CU vector index: 2
 
 ; CHECK:      Constant pool offset = 0x2060, has 3 CU vectors:
 ; CHECK-NEXT:   0(0x0): 0x30000000 
 ; CHECK-NEXT:   1(0x8): 0x90000000 0x90000001
 ; CHECK-NEXT:   2(0x14): 0x30000001