public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Alan Modra <amodra@bigpond.net.au>
To: Bob Wilson <bwilson@tensilica.com>
Cc: binutils@sources.redhat.com
Subject: Re: [PATCH] orphan section creating huge output file
Date: Thu, 17 Mar 2005 08:13:00 -0000	[thread overview]
Message-ID: <20050317042242.GK21148@bubble.modra.org> (raw)
In-Reply-To: <4238E8CA.5080001@tensilica.com>

On Wed, Mar 16, 2005 at 06:17:46PM -0800, Bob Wilson wrote:
> A while back, David Heine found a problem where an orphan section could 
> cause the linker to create huge output files, or even segfault when trying 
> to seek to a negative value.  (See 
> http://sourceware.org/ml/binutils/2003-04/msg00423.html) This problem was 
>  fixed earlier, but now he's found a similar problem.
> 
> David analyzed this and sent me an earlier version of this patch, so I'll 
> try to describe this as best I can.  The use of IGNORE_SECTION in 
> lang_size_sections_1() in ldlang.c is not right because at that point the 
> section sizes are all zero, and IGNORE_SECTION is true for zero size 
> sections.

Yes, I agree that a test of output section size at that point in
lang_size_sections_1 is wrong, but it might be appropriate if the memory
region checks were moved after the output section size had been
calculated.  Alex, you added the zero size check in
http://sources.redhat.com/ml/binutils/2003-10/msg00184.html, but I don't
see any testcase or description of exactly why the change was needed.
Given this situation, I'm going to approve this patch, especially
as the testcase demonstrates that zero size sections not allocated to
memory regions can cause ld to misbehave.

> Moreover, even a zero size section can cause the huge output file 
> problem.  The attached patch moves the check for zero size sections out of 
> the IGNORE_SECTION macro.  David also provided a testcase to demonstrate 
> the problem, and I've cleaned it up and added it to the testsuite.
> 
> OK for mainline?

Yes, and for the 2.16 branch too, but give Daniel and others a chance to
object.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

  reply	other threads:[~2005-03-17  4:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-17  4:41 Bob Wilson
2005-03-17  8:13 ` Alan Modra [this message]
2005-03-17  8:36   ` Daniel Jacobowitz
2005-03-17 14:46   ` Alexandre Oliva

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=20050317042242.GK21148@bubble.modra.org \
    --to=amodra@bigpond.net.au \
    --cc=binutils@sources.redhat.com \
    --cc=bwilson@tensilica.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).