public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Fangrui Song <i@maskray.me>
To: Pete Dietl <petedietl@gmail.com>
Cc: binutils@sourceware.org, Nick Clifton <nickc@redhat.com>
Subject: Re: Readelf section header printing alignment
Date: Fri, 5 Jan 2024 22:55:00 -0800	[thread overview]
Message-ID: <DS7PR12MB5765E0DAAAE3C9A2F5FC6E94CB652@DS7PR12MB5765.namprd12.prod.outlook.com> (raw)
In-Reply-To: <6bed5ea7-c174-4ef5-a329-48a116d55d7e@redhat.com>

On Fri, Jan 5, 2024 at 7:12 AM Nick Clifton <nickc@redhat.com> wrote:
>
> Hi Pete,
>
> > The section headers output from readelf with the '-W' option become ugly and
> > unaligned when a section name is too long.
>
> Agreed.  In hindsight it would have been better to emit the section name
> as the last entry on the output line, rather than the second.
>
> If it helps you could try using the readelf program the elfutils project
> (eu-readelf) as this appear to adjust the column positions to allow for
> extra long section names.  I think that this is a bad idea however as
> it could end up looking very strange if just one section has an extremely
> long section name.
>
> Changing the default output layout now would be a bad idea as there
> are scripts and tools out there that depend upon the current behaviour.
>
> It would be possible however to add a new command line option which
> would change the layout.  Perhaps simply --section-name-at-end ?
> Although this seems a bit, hmm, hackish.  Or maybe:
>
>    --section-listing-layout=[number,name,type,addr,off,size,flags,info,align]
>
> Then this option could be used to just display the fields of interest
> to the user, in the order that they want.  So:
>
>    --section-listing-layout=type,size,name
>
> would produce output like this:
>
>    Section Headers:
>      Type      Size     Name
>      NULL           0
>      PROGBITS  00000f  .text
>      PROGBITS  000000  .data
>      NOBITS    000000  .bss
>      PROGBITS  00002c  .comment
>      PROGBITS  000000  .note.GNU-stack
>      NOTE      000020  .note.gnu.property
>
> whereas:
>
>   --section-listing-layout=name,size
>
> would produce output like this:
>
>    Section Headers:
>      Name Size
>        0
>      .text 00000f
>      .data 000000
>      .bss  000000
>      .comment 00002c
>      .note.GNU-stack 000000
>      .note.gnu.property 000020
>
> I am just theorizing however.  I am not actually volunteering to write
> the code.  But, as they say, "patches welcome"...
>
> Cheers
>    Nick
>

> i think all of the cols can get unaligned if the content is bigger than the
> allocated space.  i wish it would autoalign/fix itself, at least when using
> the -W option.

Both eu-readelf and llvm-readelf simply ignore -W/--wide and do not
implement the narrow output at all.
Many folks like me always prefer -W since the narrow output for
certain features has truncated output (e.g. -s output truncates the
symbol name).

If a tool reads readelf -W output and will be broken due to readelf -W
changing the number of spaces, the tool is very likely broken dealing
with the object file in the first place.
To elaborate on what Mike mentioned, columns like (Flg,Lk,Inf,Al) have
the length problem as well... Fixing it will make the code more
complex, so perhaps we can recognize the problem and leave things
as-is...

Note: section warnings immediately follow the section row and
precomputing the column size can easily change the output, though it
probably doesn't matter.

% readelf -S a32
There are 4 section headers, starting at offset 0x54:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
readelf: Warning: [ 1]: Unexpected value (1) in info field.
  [ 1] .foo              PROGBITS        00000002 000037 000003 06  WA  4   1  5
readelf: Warning: section 1: sh_link value of 4 is larger than the
number of sections
  [ 2] .strtab           STRTAB          00000000 00003a 000001 00      0   0  1
  [ 3] .shstrtab         STRTAB          00000000 00003b 000018 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  D (mbind), p (processor specific)

      reply	other threads:[~2024-01-06  6:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-26 23:01 Pete Dietl
2023-12-26 23:59 ` Mike Frysinger
2024-01-05 15:12 ` Nick Clifton
2024-01-06  6:55   ` Fangrui Song [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DS7PR12MB5765E0DAAAE3C9A2F5FC6E94CB652@DS7PR12MB5765.namprd12.prod.outlook.com \
    --to=i@maskray.me \
    --cc=binutils@sourceware.org \
    --cc=nickc@redhat.com \
    --cc=petedietl@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).