[llvm-objdump] Add `Version Definitions` dumper

[Higuoxing]

Summary

llvm-objdump needs a Version Definitions dumper.

[grimar]

This LGTM. A minor suggestion is inline.
Please wait for @jhenderson opinion too.

tools/llvm-objdump/ELFDump.cpp

310

You can start from 1:

VerdefIndex = 1;

313

And do:

outs() << VerdefIndex++ << " "

[Higuoxing]

Updating D58615: [llvm-objdump] Add Version Definitions dumper

[Higuoxing]

tools/llvm-objdump/ELFDump.cpp

313

Oh, that's cool! Thanks a lot.

[jhenderson]

How many verdefs do you get in a typical file? I'm looking at the hard-coded indentation amount of Verdaux entries after the first, and thinking that that indentation doesn't look quite right, and would look worse the higher the index, due to the first column changing in width. I think it should line up with the previous name, but I don't think it currently does. Additionally, if I'm not mistaken the formatting will look something like:

1 0x01 0x075bcd15 foo
2 0x02 0x3ade68b1 VERSION_1
...
9 0xab 0x12345678 something
10 0xdc 0xabcdef90 something_else

which doesn't look great. Assuming it's not unusual to have 10+ entries, could you do something that ensures the column width is consistent?

tools/llvm-objdump/ELFDump.cpp

314

This only prints a width of 2, but the flags could require four digits. Are there never any flags beyond 0xff?

[Higuoxing]

In D58615#1409090, @jhenderson wrote:

How many verdefs do you get in a typical file? I'm looking at the hard-coded indentation amount of Verdaux entries after the first, and thinking that that indentation doesn't look quite right, and would look worse the higher the index, due to the first column changing in width. I think it should line up with the previous name, but I don't think it currently does. Additionally, if I'm not mistaken the formatting will look something like:

1 0x01 0x075bcd15 foo
2 0x02 0x3ade68b1 VERSION_1
...
9 0xab 0x12345678 something
10 0xdc 0xabcdef90 something_else

which doesn't look great. Assuming it's not unusual to have 10+ entries, could you do something that ensures the column width is consistent?

I think there could be an object file that has over 10 entries in its verdef section.
However, gnu-objdump has the same problem. I currently have no idea how to make it compatible with gnu-objdump and ensure the column width is consistent.

--- !ELF
FileHeader:
  Class:           ELFCLASS64
  Data:            ELFDATA2LSB
  Type:            ET_DYN
  Machine:         EM_X86_64
  Entry:           0x0000000000001000
Sections:
  - Name:            .gnu.version_d
    Type:            SHT_GNU_verdef
    Flags:           [ SHF_ALLOC ]
    Address:         0x0000000000000230
    Link:            .dynstr
    AddressAlign:    0x0000000000000004
    Info:            0x0000000000000010
    Entries:
      - Version:         1
        Flags:           1
        VersionNdx:      1
        Hash:            123456789
        Names:
          - VERSION_1
      - Version:         1
        Flags:           2
        VersionNdx:      2
        Hash:            987654321
        Names:
          - VERSION_2
      - Version:         1
        Flags:           2
        VersionNdx:      3
        Hash:            98765321
        Names:
          - VERSION_3
      - Version:         1
        Flags:           2
        VersionNdx:      4
        Hash:            98654321
        Names:
          - VERSION_4
      - Version:         1
        Flags:           2
        VersionNdx:      5
        Hash:            98765421
        Names:
          - VERSION_5
      - Version:         1
        Flags:           2
        VersionNdx:      6
        Hash:            989654321
        Names:
          - VERSION_6
      - Version:         1
        Flags:           2
        VersionNdx:      7
        Hash:            997654321
        Names:
          - VERSION_7
      - Version:         1
        Flags:           2
        VersionNdx:      8
        Hash:            997654321
        Names:
          - VERSION_8
      - Version:         1
        Flags:           2
        VersionNdx:      9
        Hash:            997654321
        Names:
          - VERSION_9
      - Version:         1
        Flags:           2
        VersionNdx:      10
        Hash:            997654321
        Names:
          - VERSION_10
      - Version:         1
        Flags:           2
        VersionNdx:      11
        Hash:            997654321
        Names:
          - VERSION_11
      - Version:         1
        Flags:           2
        VersionNdx:      12
        Hash:            997654321
        Names:
          - VERSION_12
      - Version:         1
        Flags:           2
        VersionNdx:      13
        Hash:            997654321
        Names:
          - VERSION_13
DynamicSymbols:
  Global:
    - Name:            bar
...

tools/llvm-objdump/ELFDump.cpp

314

As for vd_flags field, its value can be 0x01(VER_FLG_BASE) or 0x02(VER_FLG_WEAK).
See, https://docs.oracle.com/cd/E19957-01/806-0641/chapter6-80869/index.html

[jhenderson]

In D58615#1409166, @Higuoxing wrote:

In D58615#1409090, @jhenderson wrote:

How many verdefs do you get in a typical file? I'm looking at the hard-coded indentation amount of Verdaux entries after the first, and thinking that that indentation doesn't look quite right, and would look worse the higher the index, due to the first column changing in width. I think it should line up with the previous name, but I don't think it currently does. Additionally, if I'm not mistaken the formatting will look something like:

1 0x01 0x075bcd15 foo
2 0x02 0x3ade68b1 VERSION_1
...
9 0xab 0x12345678 something
10 0xdc 0xabcdef90 something_else

which doesn't look great. Assuming it's not unusual to have 10+ entries, could you do something that ensures the column width is consistent?

I think there could be an object file that has over 10 entries in its verdef section.
However, gnu-objdump has the same problem. I currently have no idea how to make it compatible with gnu-objdump and ensure the column width is consistent.

In general, we have not been aiming to be output-identical to GNU tools, but to be similar enough so that the output is clear. Where there are clear improvements to be had, we have done so. As such, I don't think you need to match GNU objdump's output byte for byte here. I would recommend left-padding the index column with spaces as needed. As for the aux fields, I would pad it so that it lines up exactly with the name above it.

[Higuoxing]

Updating D58615: [llvm-objdump] Add Version Definitions dumper

[Higuoxing]

I found a way that not so elegant to solve this problem. We assume that the verdef section contains no greater than 99 entries, then according to the index print some hard coded blank spaces.

[jhenderson]

test/tools/llvm-objdump/verdef-many-entries-elf.test

4 ↗

(On Diff #188317)

By default FileCheck treats all consecutive whitespace as a single space, both in input and check patterns, unless you specify --strict-whitespace. I don't think you need to go down this approach, so I don't think you need a test for so many entries (but it's up to you).

tools/llvm-objdump/ELFDump.cpp

312

"entries of verdef section" -> "entries in the SHT_GNU_verdef" section. You have also manually formatted the paragraph, with line breaks that are too early, rather than letting clang-format do it for you.

316

You are going along the right lines here, by using sh_info, but I don't think you should make any assumptions about the maximum number of entries, except that it won't be greater than 2^32 - 1. Better would be to simply convert sh_info to a string and use string.size() to get the required width.

329–330

Rather than hard-coding the number of spaces here, use std::string(size, ' ') to create a string of spaces. You can base the size on VerdefIndexWidth.

[Higuoxing]

Updating D58615: [llvm-objdump] Add Version Definitions dumper

[jhenderson]

LGTM, with one nit still.

tools/llvm-objdump/ELFDump.cpp

312

"entries of" -> "entries in the"

(like I already requested...)

[Higuoxing]

Updating D58615: [llvm-objdump] Add Version Definitions dumper

@jhenderson, @grimar thank you very much!

test/tools/llvm-objdump/verdef-elf.test

+# RUN: yaml2obj %s > %t
+# RUN: llvm-objdump -p %t | FileCheck %s
+
+# CHECK:      Version definitions:
+# CHECK-NEXT: 1 0x01 0x075bcd15 foo
+# CHECK-NEXT: 2 0x02 0x3ade68b1 VERSION_1
+# CHECK-NEXT:   VERSION_2 
+
+--- !ELF
+FileHeader:
+  Class:           ELFCLASS64
+  Data:            ELFDATA2LSB
+  Type:            ET_DYN
+  Machine:         EM_X86_64
+  Entry:           0x0000000000001000
+Sections:
+  - Name:            .gnu.version_d
+    Type:            SHT_GNU_verdef
+    Flags:           [ SHF_ALLOC ]
+    Address:         0x0000000000000230
+    Link:            .dynstr
+    AddressAlign:    0x0000000000000004
+    Info:            0x0000000000000003
+    Entries:
+      - Version:         1
+        Flags:           1
+        VersionNdx:      1
+        Hash:            123456789
+        Names:
+          - foo
+      - Version:         1
+        Flags:           2
+        VersionNdx:      2
+        Hash:            987654321
+        Names:
+          - VERSION_1
+          - VERSION_2
+DynamicSymbols:
+  Global:
+    - Name:            bar
+...

tools/llvm-objdump/ELFDump.cpp

while (BufAux) {
              << StringRef(StrTab.drop_front(Vernaux->vna_name).data()) << '\n';
       BufAux = Vernaux->vna_next ? BufAux + Vernaux->vna_next : nullptr;
     }
     Buf = Verneed->vn_next ? Buf + Verneed->vn_next : nullptr;
   }
 }
 
 template <class ELFT>
+void printSymbolVersionDefinition(ArrayRef<uint8_t> Contents,
+                                  StringRef StrTab) {
+  typedef ELFFile<ELFT> ELFO;
+  typedef typename ELFO::Elf_Verdef Elf_Verdef;
+  typedef typename ELFO::Elf_Verdaux Elf_Verdaux;
+
+  outs() << "Version definitions:\n";
+
+  const uint8_t *Buf = Contents.data();
+  uint32_t VerdefIndex = 1;
+  while (Buf) {
+    const Elf_Verdef *Verdef = reinterpret_cast<const Elf_Verdef *>(Buf);
+    outs() << VerdefIndex ++ << " "
+           << format("0x%02" PRIx16 " ", (uint16_t)Verdef->vd_flags)
+           << format("0x%08" PRIx32 " ", (uint32_t)Verdef->vd_hash);
+
+    const uint8_t *BufAux = Buf + Verdef->vd_aux;
+    uint16_t VerdauxIndex = 0;
+    while (BufAux) {
+      const Elf_Verdaux *Verdaux =
+          reinterpret_cast<const Elf_Verdaux *>(BufAux);
+      outs() << ((VerdauxIndex == 0) ? "" : "        ")
+             << StringRef(StrTab.drop_front(Verdaux->vda_name).data()) << '\n';
+      BufAux = Verdaux->vda_next ? BufAux + Verdaux->vda_next : nullptr;
+      ++VerdauxIndex;
+    }
+    Buf = Verdef->vd_next ? Buf + Verdef->vd_next : nullptr;
+  }
+}
+
+template <class ELFT>
 void printSymbolVersionInfo(const ELFFile<ELFT> *Elf, StringRef FileName) {
   typedef typename ELFT::Shdr Elf_Shdr;
 
   auto SectionsOrError = Elf->sections();
   if (!SectionsOrError)
     report_error(FileName, SectionsOrError.takeError());
 
   for (const Elf_Shdr &Shdr : *SectionsOrError) {
-    if (Shdr.sh_type != ELF::SHT_GNU_verneed)
+    if (Shdr.sh_type != ELF::SHT_GNU_verneed &&
+        Shdr.sh_type != ELF::SHT_GNU_verdef)
       continue;
 
     auto ContentsOrError = Elf->getSectionContents(&Shdr);
     if (!ContentsOrError)
       report_error(FileName, ContentsOrError.takeError());
 
     auto StrTabSecOrError = Elf->getSection(Shdr.sh_link);
     if (!StrTabSecOrError)
       report_error(FileName, StrTabSecOrError.takeError());
 
     auto StrTabOrError = Elf->getStringTable(*StrTabSecOrError);
     if (!StrTabOrError)
       report_error(FileName, StrTabOrError.takeError());
 
+    if (Shdr.sh_type == ELF::SHT_GNU_verneed)
       printSymbolVersionDependency<ELFT>(*ContentsOrError, *StrTabOrError);
-    // TODO: Implement symbol version definitions dumper.
+    else
+      printSymbolVersionDefinition<ELFT>(*ContentsOrError, *StrTabOrError);
   }
 }
 
 void llvm::printELFFileHeader(const object::ObjectFile *Obj) {
   if (const auto *ELFObj = dyn_cast<ELF32LEObjectFile>(Obj))
     printProgramHeaders(ELFObj->getELFFile());
   else if (const auto *ELFObj = dyn_cast<ELF32BEObjectFile>(Obj))
     printProgramHeaders(ELFObj->getELFFile());