public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nick Clifton <nickc@redhat.com>
To: Pete Dietl <petedietl@gmail.com>, binutils@sourceware.org
Subject: Re: Readelf section header printing alignment
Date: Fri, 5 Jan 2024 15:12:42 +0000	[thread overview]
Message-ID: <6bed5ea7-c174-4ef5-a329-48a116d55d7e@redhat.com> (raw)
In-Reply-To: <CACB-c0GfaStgy+7WFF-70qsGh8qbgzgVP3Jzdz_6ejwe5JiKww@mail.gmail.com>

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


  parent reply	other threads:[~2024-01-05 15:12 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 [this message]
2024-01-06  6:55   ` Fangrui Song

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=6bed5ea7-c174-4ef5-a329-48a116d55d7e@redhat.com \
    --to=nickc@redhat.com \
    --cc=binutils@sourceware.org \
    --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).