public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* [rx,head,2.21] fix lma/vma swap when reading executables in
@ 2011-05-23 19:51 DJ Delorie
  2011-05-24  3:34 ` Alan Modra
  0 siblings, 1 reply; 4+ messages in thread
From: DJ Delorie @ 2011-05-23 19:51 UTC (permalink / raw)
  To: binutils


Without this, it's impossible to "objcopy elf srec" as the addresses
in the srec are incorrect.  Also affects gdb.  Applied to both head
and 2.21 branch.

	* elf32-rx.c (rx_elf_object_p): When reading an RX object in, undo
	the vma/lma swapping done in elf32_rx_modify_program_headers.

 
Index: bfd/elf32-rx.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-rx.c,v
retrieving revision 1.10
diff -p -U5 -r1.10 elf32-rx.c
--- bfd/elf32-rx.c	17 May 2011 16:02:31 -0000	1.10
+++ bfd/elf32-rx.c	23 May 2011 19:48:06 -0000
@@ -2952,12 +2952,62 @@ elf32_rx_machine (bfd * abfd)
 }
 
 static bfd_boolean
 rx_elf_object_p (bfd * abfd)
 {
+  int i;
+  unsigned int u;
+  Elf_Internal_Phdr *phdr = elf_tdata (abfd)->phdr;
+  int nphdrs = elf_elfheader (abfd)->e_phnum;
+  sec_ptr bsec;
+
   bfd_default_set_arch_mach (abfd, bfd_arch_rx,
 			     elf32_rx_machine (abfd));
+
+  /* For each PHDR in the object, we must find some section that
+     corresponds (based on matching file offsets) and use its VMA
+     information to reconstruct the p_vaddr field we clobbered when we
+     wrote it out.  */
+  for (i=0; i<nphdrs; i++)
+    {
+      for (u=0; u<elf_tdata(abfd)->num_elf_sections; u++)
+	{
+	  Elf_Internal_Shdr *sec = elf_tdata(abfd)->elf_sect_ptr[u];
+
+	  if (phdr[i].p_offset <= (bfd_vma) sec->sh_offset
+	      && (bfd_vma)sec->sh_offset <= phdr[i].p_offset + (phdr[i].p_filesz - 1))
+	    {
+	      /* Found one!  The difference between the two addresses,
+		 plus the difference between the two file offsets, is
+		 enough information to reconstruct the lma.  */
+
+	      /* Example where they aren't:
+		 PHDR[1] = lma fffc0100 offset 00002010 size 00000100
+		 SEC[6]  = vma 00000050 offset 00002050 size 00000040
+
+		 The correct LMA for the section is fffc0140 + (2050-2010).
+	      */
+
+	      phdr[i].p_vaddr = sec->sh_addr + (sec->sh_offset - phdr[i].p_offset);
+	      break;
+	    }
+	}
+
+      /* We must update the bfd sections as well, so we don't stop
+	 with one match.  */
+      bsec = abfd->sections;
+      while (bsec)
+	{
+	  if (phdr[i].p_vaddr <= bsec->lma
+	      && bsec->vma <= phdr[i].p_vaddr + (phdr[i].p_filesz - 1))
+	    {
+	      bsec->lma = phdr[i].p_paddr + (bsec->vma - phdr[i].p_vaddr);
+	    }
+	  bsec = bsec->next;
+	}
+    }
+
   return TRUE;
 }
  \f
 
 #ifdef DEBUG

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [rx,head,2.21] fix lma/vma swap when reading executables in
  2011-05-23 19:51 [rx,head,2.21] fix lma/vma swap when reading executables in DJ Delorie
@ 2011-05-24  3:34 ` Alan Modra
  2011-05-24  3:58   ` DJ Delorie
  0 siblings, 1 reply; 4+ messages in thread
From: Alan Modra @ 2011-05-24  3:34 UTC (permalink / raw)
  To: DJ Delorie; +Cc: binutils

On Mon, May 23, 2011 at 03:50:43PM -0400, DJ Delorie wrote:
> +  /* For each PHDR in the object, we must find some section that

Limit to just PT_LOAD phdrs?

-- 
Alan Modra
Australia Development Lab, IBM

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [rx,head,2.21] fix lma/vma swap when reading executables in
  2011-05-24  3:34 ` Alan Modra
@ 2011-05-24  3:58   ` DJ Delorie
  2011-05-24  6:27     ` Alan Modra
  0 siblings, 1 reply; 4+ messages in thread
From: DJ Delorie @ 2011-05-24  3:58 UTC (permalink / raw)
  To: Alan Modra; +Cc: binutils


> On Mon, May 23, 2011 at 03:50:43PM -0400, DJ Delorie wrote:
> > +  /* For each PHDR in the object, we must find some section that
> 
> Limit to just PT_LOAD phdrs?

You could, but it shouldn't matter - it only affects the VMA of
segments and the LMA of sections.  The segments would only be used by,
for example, SREC outputs, which only use PT_LOAD anyway, and sections
are normally used for their VMA, not LMA.  I haven't verified this,
but I think it might compute the correct values anyway - the altered
field is not used in computations on read-in.

I'll add one if you want, though.  It would add symmetry :-) (and
paranoia)

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [rx,head,2.21] fix lma/vma swap when reading executables in
  2011-05-24  3:58   ` DJ Delorie
@ 2011-05-24  6:27     ` Alan Modra
  0 siblings, 0 replies; 4+ messages in thread
From: Alan Modra @ 2011-05-24  6:27 UTC (permalink / raw)
  To: DJ Delorie; +Cc: binutils

On Mon, May 23, 2011 at 11:58:15PM -0400, DJ Delorie wrote:
> 
> > On Mon, May 23, 2011 at 03:50:43PM -0400, DJ Delorie wrote:
> > > +  /* For each PHDR in the object, we must find some section that
> > 
> > Limit to just PT_LOAD phdrs?
> 
> You could, but it shouldn't matter - it only affects the VMA of
> segments and the LMA of sections.  The segments would only be used by,
> for example, SREC outputs, which only use PT_LOAD anyway, and sections
> are normally used for their VMA, not LMA.  I haven't verified this,
> but I think it might compute the correct values anyway - the altered
> field is not used in computations on read-in.
> 
> I'll add one if you want, though.  It would add symmetry :-) (and
> paranoia)

I think it might work better..  Other phdrs (with zero p_offset and
p_filesz) will match all sections the way you've written the tests.

-- 
Alan Modra
Australia Development Lab, IBM

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-05-24  6:27 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-23 19:51 [rx,head,2.21] fix lma/vma swap when reading executables in DJ Delorie
2011-05-24  3:34 ` Alan Modra
2011-05-24  3:58   ` DJ Delorie
2011-05-24  6:27     ` Alan Modra

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).