[PATCH] orphan section creating huge output file

[PATCH] orphan section creating huge output file

[Bob Wilson]

[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]

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. 
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?


ld/ChangeLog:

2005-03-16  David Heine  <dlheine@tensilica.com>
             Bob Wilson  <bob.wilson@acm.org>

         * ldlang.c (IGNORE_SECTION): Remove check for zero size.
         (lang_check_section_addresses): Ignore zero size sections here.

ld/testsuite/ChangeLog:

2005-03-16  David Heine  <dlheine@tensilica.com>
             Bob Wilson  <bob.wilson@acm.org>

         * ld-scripts/empty-orphan.d, ld-scripts/empty-orphan.exp,
         ld-scripts/empty-orphan.s, ld-scripts/emtpy-orphan.t: New test.


[-- Attachment #2: empty-orphan.patch --]
[-- Type: text/plain, Size: 3510 bytes --]

Index: ldlang.c
===================================================================
RCS file: /cvs/src/src/ld/ldlang.c,v
retrieving revision 1.174
diff -u -p -r1.174 ldlang.c
--- ldlang.c	16 Mar 2005 21:52:42 -0000	1.174
+++ ldlang.c	17 Mar 2005 01:56:12 -0000
@@ -3300,8 +3300,7 @@ size_input_section
   ((s->flags & SEC_NEVER_LOAD) != 0				\
    || (s->flags & SEC_ALLOC) == 0				\
    || ((s->flags & SEC_THREAD_LOCAL) != 0			\
-	&& (s->flags & SEC_LOAD) == 0)				\
-   || s->size == 0)
+	&& (s->flags & SEC_LOAD) == 0))
 
 /* Check to see if any allocated sections overlap with other allocated
    sections.  This can happen if a linker script specifies the output
@@ -3318,7 +3317,7 @@ lang_check_section_addresses (void)
       asection *os;
 
       /* Ignore sections which are not loaded or which have no contents.  */
-      if (IGNORE_SECTION (s))
+      if (IGNORE_SECTION (s) || s->size == 0)
 	continue;
 
       /* Once we reach section 's' stop our seach.  This prevents two
@@ -3332,7 +3331,7 @@ lang_check_section_addresses (void)
 	  bfd_vma os_end;
 
 	  /* Only consider loadable sections with real contents.  */
-	  if (IGNORE_SECTION (os))
+	  if (IGNORE_SECTION (os) || os->size == 0)
 	    continue;
 
 	  /* We must check the sections' LMA addresses not their
--- /dev/null	2005-03-03 02:28:48.304630480 -0800
+++ ld/testsuite/ld-scripts/empty-orphan.d	2005-03-16 17:46:07.037852112 -0800
@@ -0,0 +1,3 @@
+#source: empty-orphan.s
+#ld: -T empty-orphan.t
+#error: no memory region specified for loadable section
--- /dev/null	2005-03-03 02:28:48.304630480 -0800
+++ ld/testsuite/ld-scripts/empty-orphan.exp	2005-03-16 17:51:55.112721910 -0800
@@ -0,0 +1,27 @@
+# Make sure orphan sections do not lead to huge output files.
+# By David Heine, Tensilica, Inc.
+#   Copyright 2005
+#   Free Software Foundation, Inc.
+#
+# This file is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+
+# PHDRS is only meaningful for ELF.
+if ![is_elf_format] {
+    return
+}
+
+set testname "empty-orphan"
+
+run_dump_test empty-orphan
--- /dev/null	2005-03-03 02:28:48.304630480 -0800
+++ ld/testsuite/ld-scripts/empty-orphan.s	2005-03-16 17:55:04.674395168 -0800
@@ -0,0 +1,4 @@
+	.section .orphan_data, "a"
+	# empty but defined
+	.section .data
+	.word 0x1111
--- /dev/null	2005-03-03 02:28:48.304630480 -0800
+++ ld/testsuite/ld-scripts/empty-orphan.t	2005-03-16 17:55:14.630905387 -0800
@@ -0,0 +1,21 @@
+MEMORY
+{
+  default_mem : ORIGIN = 0x0, LENGTH = 0x100000
+  text_mem : ORIGIN = 0x60000000, LENGTH = 0x100
+  data_mem : ORIGIN = 0x70000000, LENGTH = 0x100
+}
+
+PHDRS
+{
+  default_phdr PT_LOAD;
+  text_phdr PT_LOAD;
+  data_phdr PT_LOAD;
+}
+
+SECTIONS
+{
+   .text : { *(.text) } > text_mem : text_phdr
+   .data : { *(.data) } > data_mem : data_phdr
+   .bss : { *(.bss) } > data_mem : data_phdr
+   /* .orphan_data is an orphan */
+}

Re: [PATCH] orphan section creating huge output file

[Alan Modra]

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

Re: [PATCH] orphan section creating huge output file

[Daniel Jacobowitz]

On Thu, Mar 17, 2005 at 02:52:42PM +1030, Alan Modra wrote:
> Yes, and for the 2.16 branch too, but give Daniel and others a chance to
> object.

Go right ahead; a testcase is pretty convincing.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [PATCH] orphan section creating huge output file

[Alexandre Oliva]

On Mar 17, 2005, Alan Modra <amodra@bigpond.net.au> wrote:

> 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.

Uhh...  Sorry about that.  IIRC, I couldn't come up with a small
testcase at that time.  I think the problem was triggered linking the
linux kernel, using memory region definitions that didn't cover all of
the sections specified in the linker scripts.  All the relevant ones
were assigned to specific memory regions, but ones that didn't exist
in the default linker script at the time the memory region assignment
was created, and that were not present in any of the input files, were
flagged with errors.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}