From: Hans-Peter Nilsson <hp@bitrange.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Nick Clifton <nickc@redhat.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 22:51:38 -0400 (EDT) [thread overview]
Message-ID: <alpine.BSF.2.20.16.2004212246360.59409@arjuna.pair.com> (raw)
In-Reply-To: <38ac9399-f2e7-2b9d-cd1c-154409738c51@suse.com>
On Tue, 21 Apr 2020, Jan Beulich wrote:
> On 21.04.2020 12:01, Nick Clifton wrote:
> > 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.
(Not this one.)
> > * 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...
Hm; regarding "--enable-*". I don't mind the names, but you're
not going to make these *configure-time* options, right?
> >
> > * 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,
[...]
> > 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 -
[...]
Agree with what Jan wrote (including what I pruned).
brgds, H-P
next prev parent reply other threads:[~2020-04-22 2:51 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
2020-04-22 2:51 ` Hans-Peter Nilsson [this message]
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=alpine.BSF.2.20.16.2004212246360.59409@arjuna.pair.com \
--to=hp@bitrange.com \
--cc=binutils@sourceware.org \
--cc=hjl.tools@gmail.com \
--cc=jbeulich@suse.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).