Subject: RE: objcopy error -- was RE: your mail

From: John Van Horne <[email-masked]>
Date: Thu, 4 Jan 2001 14:00:59 -0800

This is the same script that worked fine when we were using 
egcs-mips-linux-1.0.3a and binutils-mips-linux-2.8.1.  Have
there been any changes in the linker that would affect how
we write our linker script?

Thanks,
-John

-----Original Message-----
From: Maciej W. Rozycki [mailto:[email-masked]]
Sent: Thursday, January 04, 2001 1:18 PM
To: John Van Horne
Cc: [email-masked]'
Subject: Re: objcopy error -- was RE: your mail

On Thu, 4 Jan 2001, John Van Horne wrote:

> [jvhorne@guava-lx linux]$ make orionboot
> make -C arch/mips/orion orionboot
> make[1]: Entering directory
>
`/dvlp/jvhorne/jvh_21_lx_mips_cross_test_sv/vobs/gpl/linux/arch/mips/orion'
> mips-linux-objcopy -Obinary --verbose ../../../vmlinux orion.nosym
> copy from ../../../vmlinux(elf32-bigmips) to orion.nosym(binary)
> BFD: Warning: Writing section `.app_header' to huge (ie negative) file
> offset 0x800fec30.
> BFD: Warning: Writing section `.text' to huge (ie negative) file offset
> 0x80100c30.
> BFD: Warning: Writing section `.fixup' to huge (ie negative) file offset
> 0x80236930.
> BFD: Warning: Writing section `.text.exit' to huge (ie negative) file
offset
> 0x80237830.
> .
> .
> .
> mips-linux-objcopy: orion.nosym: File truncated
> 
> 
> Do you think that the reason objcopy fails is because it isn't treating
> the addresses as 32 bit addresses, or could it be something else?

 Note that the binary BFD target fills all "holes" with zeroes.  I suspect
one or more sections are placed at an offset lower than 0x80000000. 
Objcopy would have to make a huge file in this case and it gives up.  You
probably need to fix your linker script.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Fri, 5 Jan 2001 12:55:41 +0100 (MET)

> we write our linker script?

 It's possible the linker emits unnecessary sections.  Try the following
patch to see if it helps.

2000-11-30  Ralf Baechle  <[email-masked]>

        * elf32-mips.c (elf32_mips_merge_private_bfd_data): Always permit
        BFDs containing no sections or empty .text, .data or .bss sections
	to be merged, regardless of their flags.

diff -urN binutils-cygnus/bfd/elf32-mips.c binutils/bfd/elf32-mips.c
--- binutils-cygnus/bfd/elf32-mips.c	Sat Oct 14 14:21:14 2000
+++ binutils/bfd/elf32-mips.c	Thu Nov 30 16:13:09 2000
@@ -2475,6 +2475,8 @@
   flagword old_flags;
   flagword new_flags;
   boolean ok;
+  boolean null_input_bfd = true;
+  asection *sec;
 
   /* Check if we have the same endianess */
   if (_bfd_generic_verify_endian_match (ibfd, obfd) == false)
@@ -2512,6 +2514,27 @@
   old_flags &= ~EF_MIPS_NOREORDER;
 
   if (new_flags == old_flags)
+    return true;
+
+  /* Check to see if the input BFD actually contains any sections.
+     If not, its flags may not have been initialised either, but it cannot
+     actually cause any incompatibility.  */
+  for (sec = ibfd->sections; sec != NULL; sec = sec->next)
+    {
+      /* Ignore synthetic sections and empty .text, .data and .bss sections
+	  which are automatically generated by gas.  */
+      if (strcmp (sec->name, ".reginfo")
+	  && strcmp (sec->name, ".mdebug")
+	  && ((!strcmp (sec->name, ".text")
+	       || !strcmp (sec->name, ".data")
+	       || !strcmp (sec->name, ".bss"))
+	      && sec->_raw_size != 0))
+	{
+	  null_input_bfd = false;
+	  break;
+	}
+    }
+  if (null_input_bfd)
     return true;
 
   ok = true;