From 8d28f606dc331fbe194fc6af8140efeadc020505 Mon Sep 17 00:00:00 2001 From: Hans-Peter Nilsson Date: Sat, 29 Jun 2002 21:45:09 +0000 Subject: [PATCH] * mmo.c (mmo_write_loc_chunk): Don't eliminate leading and trailing zero-sequences when there's previous left-over data. --- bfd/ChangeLog | 5 +++++ bfd/mmo.c | 23 +++++++++++++++-------- 2 files changed, 20 insertions(+), 8 deletions(-) diff --git a/bfd/ChangeLog b/bfd/ChangeLog index c4a68787381..a72dffb1ceb 100644 --- a/bfd/ChangeLog +++ b/bfd/ChangeLog @@ -1,3 +1,8 @@ +2002-06-29 Hans-Peter Nilsson + + * 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 * elf64-hppa.c (elf64_hppa_reloc_type_class): New function. diff --git a/bfd/mmo.c b/bfd/mmo.c index 7bf064dfc4c..96c654e8ee9 100644 --- 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. */ -- 2.30.2