From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Lance Taylor To: joel@OARcorp.com, eric@skatter.USask.Ca Cc: gas2@cygnus.com Subject: Re: binutils-2.9 objcopy fails (fwd) Date: Tue, 14 Apr 1998 13:18:00 -0000 Message-id: <199804142018.QAA16481@subrogation.cygnus.com> References: X-SW-Source: 1998/msg00121.html Date: Tue, 14 Apr 1998 14:23:14 -0500 (CDT) From: Joel Sherrill ---------- Forwarded message ---------- Date: Tue, 14 Apr 98 13:20:47 -0600 From: Eric Norum 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