This is an archive of the discontinued LLVM Phabricator instance.

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

Authored by MaskRay on Aug 6 2019, 10:35 PM.

Details

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.

Diff Detail

Repository
rL LLVM

Event Timeline

MaskRay created this revision.Aug 6 2019, 10:35 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 6 2019, 10:35 PM
jhenderson accepted this revision.Aug 7 2019, 1:55 AM

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

This revision is now accepted and ready to land.Aug 7 2019, 1:55 AM
grimar accepted this revision.Aug 7 2019, 2:01 AM

LGTM.

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...

This revision was automatically updated to reflect the committed changes.

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.

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.

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.

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.