Re: binutils-2.9 objcopy fails (fwd)

[Ian Lance Taylor <ian@cygnus.com>]

   Date: Tue, 14 Apr 1998 14:23:14 -0500 (CDT)
   From: Joel Sherrill <joel@OARcorp.com>

   ---------- Forwarded message ----------
   Date: Tue, 14 Apr 98 13:20:47 -0600
   From: Eric Norum <eric@skatter.USask.Ca>

   I downloaded and installed the latest binutils.  Now I can't  
   generate prom images any more.

   Background:
   I've got two types of 68360 systems here.  One uses a single 8-bit  
   bootstrap prom and the other uses 4 8-bit bootstrap proms as a 32-bit  
   prom.  I use a script to generate the S-record images for my prom  
   burner.

   Here are the salient lines from the script:

   m68k-rtems-objcopy --output-target=srec prom.exe prom.hex

   for byte in 0 1 2 3
   do
	   m68k-rtems-objcopy --interleave=4 --byte=$byte  
   --output-target=srec prom.exe prom$byte.hex
   done


   Problem:
   The first objcopy works fine to build the 8-bit bootstrap prom  
   image, but when I try to split the executable into the 4 images for  
   the 32-bit prom, I get:

   + m68k-rtems-objcopy --output-target=srec prom.exe prom.hex
   + m68k-rtems-objcopy --interleave=4 --byte=0 --output-target=srec  
   prom.exe prom0.hex
   m68k-rtems-objcopy: prom0.hex: Invalid operation


I can recreate this problem, but what's odd is that all of the code is
old.  What version of the binutils were you using before?  I can
recreate the problem using an binutils 2.6 I have lying around.

The problem I'm seeing is this call in copy_section in
binutils/objcopy.c:

              /* The section has gotten smaller. */
          if (!bfd_set_section_size (obfd, osection, size))
            nonfatal (bfd_get_filename (obfd));

This is trying to set the section size after objcopy has already
started to write to the sections.  This needs to be handled
differently.

Ian