* mmo.c (mmo_write_loc_chunk): Don't eliminate leading and

	trailing zero-sequences when there's previous left-over data.

diff --git a/bfd/ChangeLog b/bfd/ChangeLog
index c4a6878738122e7e3eba5c0fc35c54dfa0d10cf5..a72dffb1ceb1dfb212450c18b8013b6bfb06de04 100644 (file)
--- a/bfd/ChangeLog
+++ b/bfd/ChangeLog
@@ -1,3 +1,8 @@
+2002-06-29  Hans-Peter Nilsson  <hp@bitrange.com>
+
+       * mmo.c (mmo_write_loc_chunk): Don't eliminate leading and
+       trailing zero-sequences when there's previous left-over data.
+
 2002-06-27  John David Anglin  <dave@hiauly1.hia.nrc.ca>
 
        * elf64-hppa.c (elf64_hppa_reloc_type_class): New function.

diff --git a/bfd/mmo.c b/bfd/mmo.c
index 7bf064dfc4c003e88bd5fe24bd79dab06bf71209..96c654e8ee92dd4726c239ae6820ef56de18653e 100644 (file)
--- a/bfd/mmo.c
+++ b/bfd/mmo.c
@@ -913,16 +913,23 @@ mmo_write_loc_chunk (abfd, vma, loc, len, last_vmap)
   /* Find an initial and trailing section of zero tetras; we don't need to
      write out zeros.  FIXME: When we do this, we should emit section size
      and address specifiers, else objcopy can't always perform an identity
-     translation.  */
-  while (len >= 4 && bfd_get_32 (abfd, loc) == 0)
+     translation.  Only do this if we *don't* have left-over data from a
+     previous write or the vma of this chunk is *not* the next address,
+     because then data isn't tetrabyte-aligned and we're concatenating to
+     that left-over data.  */
+
+  if (abfd->tdata.mmo_data->byte_no == 0 || vma != *last_vmap)
     {
-      vma += 4;
-      len -= 4;
-      loc += 4;
-    }
+      while (len >= 4 && bfd_get_32 (abfd, loc) == 0)
+       {
+         vma += 4;
+         len -= 4;
+         loc += 4;
+       }
 
-  while (len >= 4 && bfd_get_32 (abfd, loc + len - 4) == 0)
-    len -= 4;
+      while (len >= 4 && bfd_get_32 (abfd, loc + len - 4) == 0)
+       len -= 4;
+    }
 
   /* Only write out the location if it's different than the one the caller
      (supposedly) previously handled, accounting for omitted leading zeros.  */