[llvm-readelf] --notes: move 'Data size' column left by 1

[MaskRay]

Summary

readelf -n:

// "Data size" is not left justified
  Owner                 Data size       Description
  GNU                  0x00000010       NT_GNU_ABI_TAG (ABI version tag)

llvm-readelf -n (before):

// "Data size" column shifted by 1
  Owner                 Data size        Description
  GNU                   0x00000010       NT_GNU_ABI_TAG (ABI version tag)

llvm-readelf -n (after):

Owner                Data size        Description
GNU                  0x00000010       NT_GNU_ABI_TAG (ABI version tag)

This change is made to reduce the diff with readelf -n, so that it is
slightly easier to check what features readelf implements but we don't.

[jhenderson]

LGTM. I assume that the 64-bit note layout (i.e. one with a 64-bit size field) works too?

[grimar]

LGTM.

[MaskRay]

In D65847#1618466, @jhenderson wrote:

LGTM. I assume that the 64-bit note layout (i.e. one with a 64-bit size field) works too?

binutils/readelf.c

printf (_("  %-20s %10s\tDescription\n"), _("Owner"), _("Data size"));

I think it is very unlikely that the size is larger than 32-bit...

[jhenderson]

In D65847#1618471, @MaskRay wrote:

In D65847#1618466, @jhenderson wrote:

LGTM. I assume that the 64-bit note layout (i.e. one with a 64-bit size field) works too?

binutils/readelf.c

printf (_("  %-20s %10s\tDescription\n"), _("Owner"), _("Data size"));

I think it is very unlikely that the size is larger than 32-bit...

I agree a large size is unlikely. I was more concerned with it adding leading zeroes (correctly/incorrectly) for 64-bit numbers if the format was 64-bits. That broke the layout of some other tools, if I remember correctly.

[MaskRay]

In D65847#1618571, @jhenderson wrote:

In D65847#1618471, @MaskRay wrote:

In D65847#1618466, @jhenderson wrote:

LGTM. I assume that the 64-bit note layout (i.e. one with a 64-bit size field) works too?

binutils/readelf.c

printf (_("  %-20s %10s\tDescription\n"), _("Owner"), _("Data size"));

I think it is very unlikely that the size is larger than 32-bit...

I agree a large size is unlikely. I was more concerned with it adding leading zeroes (correctly/incorrectly) for 64-bit numbers if the format was 64-bits. That broke the layout of some other tools, if I remember correctly.

typedef struct
{
  Elf64_Word n_namesz;			/* Length of the note's name.  */
  Elf64_Word n_descsz;			/* Length of the note's descriptor.  */
  Elf64_Word n_type;			/* Type of the note.  */
} Elf64_Nhdr;

We don't have to worry about that. n_descsz is 32-bit in both ELFCLASS32 and ELFCLASS64.

[jhenderson]

In D65847#1618644, @MaskRay wrote:

In D65847#1618571, @jhenderson wrote:

In D65847#1618471, @MaskRay wrote:

In D65847#1618466, @jhenderson wrote:

LGTM. I assume that the 64-bit note layout (i.e. one with a 64-bit size field) works too?

binutils/readelf.c

printf (_("  %-20s %10s\tDescription\n"), _("Owner"), _("Data size"));

I think it is very unlikely that the size is larger than 32-bit...

I agree a large size is unlikely. I was more concerned with it adding leading zeroes (correctly/incorrectly) for 64-bit numbers if the format was 64-bits. That broke the layout of some other tools, if I remember correctly.

typedef struct
{
  Elf64_Word n_namesz;			/* Length of the note's name.  */
  Elf64_Word n_descsz;			/* Length of the note's descriptor.  */
  Elf64_Word n_type;			/* Type of the note.  */
} Elf64_Nhdr;

We don't have to worry about that. n_descsz is 32-bit in both ELFCLASS32 and ELFCLASS64.

Okay, now that you wrote that, I remember that the gABI specification doesn't match up with practice (and I think this has been acknowledged on the mailing lists). The latest sco gABI I'm reading states "In 64-bit objects (files with e_ident[EI_CLASS] equal to ELFCLASS64), each entry is an array of 8-byte words in the format of the target processor. " But that's not what is being done in practice, so my concern is moot and a separate discussion.

[MaskRay]

In D65847#1618668, @jhenderson wrote:

In D65847#1618644, @MaskRay wrote:

In D65847#1618571, @jhenderson wrote:

In D65847#1618471, @MaskRay wrote:

In D65847#1618466, @jhenderson wrote:

LGTM. I assume that the 64-bit note layout (i.e. one with a 64-bit size field) works too?

binutils/readelf.c

printf (_("  %-20s %10s\tDescription\n"), _("Owner"), _("Data size"));

I think it is very unlikely that the size is larger than 32-bit...

I agree a large size is unlikely. I was more concerned with it adding leading zeroes (correctly/incorrectly) for 64-bit numbers if the format was 64-bits. That broke the layout of some other tools, if I remember correctly.

typedef struct
{
  Elf64_Word n_namesz;			/* Length of the note's name.  */
  Elf64_Word n_descsz;			/* Length of the note's descriptor.  */
  Elf64_Word n_type;			/* Type of the note.  */
} Elf64_Nhdr;

We don't have to worry about that. n_descsz is 32-bit in both ELFCLASS32 and ELFCLASS64.

Okay, now that you wrote that, I remember that the gABI specification doesn't match up with practice (and I think this has been acknowledged on the mailing lists). The latest sco gABI I'm reading states "In 64-bit objects (files with e_ident[EI_CLASS] equal to ELFCLASS64), each entry is an array of 8-byte words in the format of the target processor. " But that's not what is being done in practice, so my concern is moot and a separate discussion.

I recollected this difference: many implementations (Linux, FreeBSD, NetBSD, Solaris, etc) use 32-bit fields for the 64-bit note section.

llvm/trunk/test/tools/llvm-readobj/gnu-notes.test

 ## Test tools are able to dump different types of notes.
 
 # RUN: yaml2obj --docnum=1 %s > %t1.so
-# RUN: llvm-readelf --notes %t1.so | FileCheck %s --check-prefix=GNU
+# RUN: llvm-readelf --notes %t1.so | FileCheck %s --check-prefix=GNU --strict-whitespace --match-full-lines
 # RUN: llvm-readobj --notes %t1.so | FileCheck %s --check-prefix=LLVM
 
-# GNU:      Displaying notes found at file offset 0x00000200 with length 0x00000020:
-# GNU-NEXT:   Owner                 Data size       Description
-# GNU-NEXT:   GNU                   0x00000010      NT_GNU_ABI_TAG (ABI version tag)
-# GNU-NEXT:     OS: Linux, ABI: 2.6.32
+#      GNU:Displaying notes found at file offset 0x00000200 with length 0x00000020:
+# GNU-NEXT:  Owner                Data size   Description
+# GNU-NEXT:  GNU                  0x00000010  NT_GNU_ABI_TAG (ABI version tag)
+# GNU-NEXT:    OS: Linux, ABI: 2.6.32
 
-# GNU:      Displaying notes found at file offset 0x00000220 with length 0x00000020:
-# GNU-NEXT:   Owner                 Data size       Description
-# GNU-NEXT:   GNU                  0x00000010       NT_GNU_BUILD_ID (unique build ID bitstring)
-# GNU-NEXT:     Build ID: 4fcb712aa6387724a9f465a32cd8c14b
+#      GNU:Displaying notes found at file offset 0x00000220 with length 0x00000020:
+# GNU-NEXT:  Owner                Data size   Description
+# GNU-NEXT:  GNU                  0x00000010  NT_GNU_BUILD_ID (unique build ID bitstring)
+# GNU-NEXT:    Build ID: 4fcb712aa6387724a9f465a32cd8c14b
 
-# GNU:      Displaying notes found at file offset 0x00000240 with length 0x0000001c:
-# GNU-NEXT:   Owner                 Data size       Description
-# GNU-NEXT:   GNU                  0x00000009       NT_GNU_GOLD_VERSION (gold version)
-# GNU-NEXT:     Version: gold 1.11
+#      GNU:Displaying notes found at file offset 0x00000240 with length 0x0000001c:
+# GNU-NEXT:  Owner                Data size   Description
+# GNU-NEXT:  GNU                  0x00000009  NT_GNU_GOLD_VERSION (gold version)
+# GNU-NEXT:    Version: gold 1.11
 
 # LLVM:      Notes [
 # LLVM-NEXT:   NoteSection {
 # LLVM-NEXT:     Offset: 0x200
 # LLVM-NEXT:     Size: 0x20
 # LLVM-NEXT:     Note {
 # LLVM-NEXT:       Owner: GNU
 # LLVM-NEXT:       Data size: 0x10

llvm/trunk/tools/llvm-readobj/ELFDumper.cpp

 }
 
 template <class ELFT>
 void GNUStyle<ELFT>::printNotes(const ELFFile<ELFT> *Obj) {
   auto PrintHeader = [&](const typename ELFT::Off Offset,
                          const typename ELFT::Addr Size) {
     OS << "Displaying notes found at file offset " << format_hex(Offset, 10)
        << " with length " << format_hex(Size, 10) << ":\n"
-       << "  Owner                 Data size\tDescription\n";
+       << "  Owner                Data size \tDescription\n";
   };
 
   auto ProcessNote = [&](const Elf_Note &Note) {
     StringRef Name = Note.getName();
     ArrayRef<uint8_t> Descriptor = Note.getDesc();
     Elf_Word Type = Note.getType();
 
-    OS << "  " << Name << std::string(22 - Name.size(), ' ')
+    OS << "  " << left_justify(Name, 20) << ' '
        << format_hex(Descriptor.size(), 10) << '\t';
 
     if (Name == "GNU") {
       OS << getGNUNoteTypeName(Type) << '\n';
       printGNUNote<ELFT>(OS, Type, Descriptor);
     } else if (Name == "FreeBSD") {
       OS << getFreeBSDNoteTypeName(Type) << '\n';
     } else if (Name == "AMD") {