This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Objcopy fix for relocation sections


On Tue, Dec 23, 2003 at 01:51:37PM +1030, Alan Modra wrote:
> On Mon, Dec 22, 2003 at 04:05:44PM -0500, Daniel Jacobowitz wrote:
> > I got a bug report that objcopy failed for shared libraries with "File
> > truncated" on arm-linux.  The problem was that ARM keeps relocations for
> > debug information, and objcopy never arranged for
> > elf.c:assign_file_position_for_relocs to be called.  This patch was the best
> > solution I could come up with - is it OK?
> > 
> > 	* elf.c (_bfd_elf_set_section_contents): If a relocation section
> > 	does not have an offset, assign one.
> 
> I can't say I like it particularly.  I think it would be better to
> set the file offsets for relocs in assign_file_positions_except_relocs.
> I know that goes against the name of the function, but we set offsets
> for .rela.dyn and other loaded reloc sections in executables and
> shared libs there anyway..

I still haven't let this die...

Alan, your suggested patch to assign rel positions earlier does not
work.  The problem is that SHT_REL sections may not be sized yet during
linking.  If they aren't, we assign them a file position and then
assign the following section the same file position because they have a
placeholder size of 0.  My only testcase for this to date is a MIPS
bootloader, which uses --emit-relocs.  My guess is that otherwise the
relocation sections are at the end anyway.

We ought to be able to size reloc sections at this point.  We can't do
it before the call to _bfd_elf_compute_section_file_positions because
they haven't been initialized yet in a final link.  And I don't want to
do it inside _bfd_elf_compute_section_file_positions, because there are
calls to that function from other places than final link processing. 
That leads me to this patch.

I think it's right because if we are linking we'll go through the call
in elf_bfd_final_link instead, and if we're not linking then the reloc
sections will have correct sizes and can be placed earlier.  This is
similar to my previous patch, but has a better understanding behind it.

No testcase included because I'm having a really hard time writing one.
I'm not sure why.  I took an existing library that used to show the
problem and verified that the patch still works; it also does not
introduce the corrupted ELF file when building the bootloader ("colo").

OK?

-- 
Daniel Jacobowitz

2004-07-27  Daniel Jacobowitz  <dan@debian.org>

	* elf.c (_bfd_elf_set_section_contents): Call
	_bfd_elf_assign_file_positions_for_relocs when starting output.

--- elf.c.orig	2004-07-27 16:32:17.000000000 -0400
+++ elf.c	2004-07-27 16:41:25.000000000 -0400
@@ -6102,9 +6102,12 @@ _bfd_elf_set_section_contents (bfd *abfd
   Elf_Internal_Shdr *hdr;
   bfd_signed_vma pos;
 
-  if (! abfd->output_has_begun
-      && ! _bfd_elf_compute_section_file_positions (abfd, NULL))
-    return FALSE;
+  if (! abfd->output_has_begun)
+    {
+      if (! _bfd_elf_compute_section_file_positions (abfd, NULL))
+	return FALSE;
+      _bfd_elf_assign_file_positions_for_relocs (abfd);
+    }
 
   hdr = &elf_section_data (section)->this_hdr;
   pos = hdr->sh_offset + offset;


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]