public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Nick Clifton <nickc@redhat.com>
Cc: Hans-Peter Nilsson <hp@bitrange.com>,
	"H.J. Lu" <hjl.tools@gmail.com>,
	Binutils <binutils@sourceware.org>
Subject: Re: [PATCH] readelf: Warn zero-sized relocation sections
Date: Tue, 21 Apr 2020 12:31:25 +0200	[thread overview]
Message-ID: <38ac9399-f2e7-2b9d-cd1c-154409738c51@suse.com> (raw)
In-Reply-To: <6e6883eb-3e70-722a-a43a-dfd5404d983e@redhat.com>

On 21.04.2020 12:01, Nick Clifton wrote:
> Hi Guys,
> 
>> Time to chime in?
> 
> Go ahead... :-)
> 
>> I'd like to voice my support for *not* have readelf emit an
>> empty-section warning by default (whether a relocation section
>> or not).  Nonetheless it would be very useful as a separate,
>> non-default, option, say for generally fishy contents.
>>
>> If it's added anyway, please also add an option to not emit the
>> warning.
> 
> I have been thinking about this.  I was wondering what the best form 
> of such an option would be.  I see three different possibilities:
> 
>   * Just warn about everything, and do not have an option.
> 
>   * Have a --enable-warnings option which is off by default
>     and which disables *all* warnings unless enabled.
>     This would mean changing the current behaviour of readelf...
> 
>   * Have a --enable-extra-warnings option which enables the zero
>     sized section test but no others.  (For now - in the future
>     I would envision us adding more tests).  For this path I
>     think that it would also make sense to warn about any zero
>     sized section that does not have the SHT_NOBITS type.

Of the three I'd vote for the last, but I don't think all zero
sized sections should be warned about. An assembly file
contributing to just .rodata still has empty .text and .data
sections in the resulting object. In this regard I also don't
see why empty NOBITS sections would be any special.

> Or maybe:
> 
>   * Have a --enable-lint (or some such name) which enables testing
>     for conformance to the ELF standard, (plus strangeness things
>     like zero sized sections).  This would count as a command option
>     in its own right, so that unless another option is provided
>     then only the warning/error messages would be displayed.

Perhaps this one's best, albeit - as per above - with there
being a definition of "strangeness" that wouldn't cause warnings
for ELF files coming out of well known (and assumed to be well
behaved) tools (e.g. including gas, gld, gold etc). I've even
want to lobby for a two stage control here - at a lower level
only ELF conformance violations would be warned about, while at
a higher level strangeness would also be complained about.
Eventually there may want to be multiple levels of strangeness.

Jan

  reply	other threads:[~2020-04-21 10:31 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-14 12:25 H.J. Lu
2020-04-14 12:42 ` Jan Beulich
2020-04-14 13:03   ` H.J. Lu
2020-04-14 13:25     ` Jan Beulich
2020-04-14 13:30       ` H.J. Lu
2020-04-14 13:38         ` Jan Beulich
2020-04-14 13:54           ` H.J. Lu
2020-04-17 15:46             ` Nick Clifton
2020-04-17 17:57               ` H.J. Lu
2020-04-18  0:26                 ` Alan Modra
2020-04-18 16:51                   ` [PATCH] elf: Strip zero-sized dynamic sections H.J. Lu
2020-04-20  9:35                     ` Alan Modra
2020-04-20 13:25                       ` V2 " H.J. Lu
2020-04-21 10:20                         ` Nick Clifton
2020-04-20  5:33               ` [PATCH] readelf: Warn zero-sized relocation sections Jan Beulich
2020-04-20 10:28                 ` Nick Clifton
2020-04-20 12:19                   ` Jan Beulich
2020-04-20 17:25                     ` Hans-Peter Nilsson
2020-04-21 10:01                       ` Nick Clifton
2020-04-21 10:31                         ` Jan Beulich [this message]
2020-04-22  2:51                           ` Hans-Peter Nilsson
2020-04-24 14:04                             ` Nick Clifton
2020-04-24 16:20                               ` Hans-Peter Nilsson
2020-04-29 15:04                                 ` Nick Clifton
2020-04-24 17:19                               ` Fangrui Song
2020-04-26 15:26                                 ` Nick Clifton
2020-04-26 15:59                                   ` H.J. Lu
2020-04-24 17:50                               ` Jan Beulich
2020-04-27 11:24                                 ` Nick Clifton

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=38ac9399-f2e7-2b9d-cd1c-154409738c51@suse.com \
    --to=jbeulich@suse.com \
    --cc=binutils@sourceware.org \
    --cc=hjl.tools@gmail.com \
    --cc=hp@bitrange.com \
    --cc=nickc@redhat.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).