public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Nick Clifton <nickc@redhat.com>
Cc: "H.J. Lu" <hjl.tools@gmail.com>, Binutils <binutils@sourceware.org>
Subject: Re: [PATCH] readelf: Warn zero-sized relocation sections
Date: Mon, 20 Apr 2020 14:19:52 +0200	[thread overview]
Message-ID: <7f05a248-7f7f-263e-29de-33e049e8c149@suse.com> (raw)
In-Reply-To: <8cdfadaa-e0f2-9ced-2359-c6ed3609154a@redhat.com>

On 20.04.2020 12:28, Nick Clifton wrote:
>>>   I am of a mind to allow this patch, given that one of readelf's
> 
>> While I can see the "diagnose problems" aspect, zero-sized relocation
>> sections aren't something the ELF standard disallows. So there's no
>> problem with the ELF files in this case, just a _possible_ problem
>> with consumers thereof.
> 
> True - but in this case we are talking about relocation sections, and
> what possible use is an empty relocation section ?  Its presence is
> legal sure, but it can also be an indication that the tool that created
> the binary is not quite doing its job properly.

It is still legitimate for a tool to create _all_ sections it may
possibly put data into. While now causing headaches, that ppc
behavior mentioned further down actually demonstrates this.

> I personally like the idea of giving users as much information as possible
> and allowing them to decide if they want it.  After all it is relatively
> easy to remove any warning out that is undesired via command line tools.

Is it, even when considering the messages getting translated to
other languages? What would my pattern be to filter them out
regardless of language?

Anyway, I merely meant to voice my opinion. You're the maintainer,
so you've got to judge.

>>>     readelf: Warning: Section '.rela.dyn': zero-sized relocation section
>>
>> Aren't these a good enough indication that zero-sized relocation
>> sections aren't this unusual, and hence a default-on warning is
>> going too far?
> 
> Actually no - these failures have now prompted H.J. and Alan to have a look
> at the code producing these empty sections and see about fixing them.

Yes, I've seen this. Not emitting these sections is certainly a
good thing to do, but aiui current behavior is still legitimate
(and hence I'd call this clean up, not "fixing").

Jan

  reply	other threads:[~2020-04-20 12:19 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 [this message]
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
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=7f05a248-7f7f-263e-29de-33e049e8c149@suse.com \
    --to=jbeulich@suse.com \
    --cc=binutils@sourceware.org \
    --cc=hjl.tools@gmail.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).