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

[James Henderson via Phabricator via llvm-commits]

jhenderson added a comment.

In D65847#1618644 <https://reviews.llvm.org/D65847#1618644>, @MaskRay wrote:

> In D65847#1618571 <https://reviews.llvm.org/D65847#1618571>, @jhenderson wrote:
>
> > In D65847#1618471 <https://reviews.llvm.org/D65847#1618471>, @MaskRay wrote:
> >
> > > In D65847#1618466 <https://reviews.llvm.org/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 <http://www.sco.com/developers/gabi/latest/ch5.pheader.html#note_section> 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.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65847/new/

https://reviews.llvm.org/D65847