This is the mail archive of the binutils@sourceware.cygnus.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]

Re: PATCH for 64-bit MIPS ELF relocations


   From: Mark Mitchell <mark@codesourcery.com>
   Date: Sat, 03 Jul 1999 18:29:07 -0700

   The 64-bit MIPS ELF ABI does not use the standard 64-bit ELF
   reocations.  Instead, it uses the special structure given by
   Elf64_External_Rel[a].  These structures allow the encoding of up to
   three relocations per physical relocation.

   Fortunately, they happen to be the same size as the standard 64-bit
   ELF relocations.  It appears that no part of BFD except the back-end
   actually looks to see what's in these structures, with the exception
   of elf_swap_reloc[a]_{in,out}.  We don't want the usual byte-swapping
   operations when using the MIPS variants; the fields lie in different
   places.

   This patch provides hooks for an ELF back-end to tweak the relocation
   swapping.  I've verified that with the appropriate changes to the
   64-bit ELF MIPS back-end the right things happen.  (Those patches are
   not included here; I'm working on other things there as well.)

Sorry it took a while to respond to this.

   @@ -2041,11 +2045,12 @@ elf_link_read_relocs_from_section (abfd,
	  irela = internal_relocs;
	  for (; erel < erelend; erel++, irela++)
	   {
   -	  Elf_Internal_Rel irel;
   -
   -	  elf_swap_reloc_in (abfd, erel, &irel);
   -	  irela->r_offset = irel.r_offset;
   -	  irela->r_info = irel.r_info;
   +	  if (bed->elf_backend_swap_reloc_in)
   +	    (*bed->elf_backend_swap_reloc_in) (abfd, 
   +					       (bfd_byte *) erel,
   +					       (Elf_Internal_Rel*) irela);
   +	  else
   +	    elf_swap_reloc_in (abfd, erel, (Elf_Internal_Rel*) irela);
	     irela->r_addend = 0;
	   }
	}

This code appears to be a type pun which relies on the fact that a
pointer to Elf_Internal_Rela can be safely cast to a pointer to
Elf_Internal_Rel, because the fields in Elf_Internal_Rel happen to be
the initial fields in Elf_Internal_Rela.  I don't like those sorts of
puns in general, and I consider this one to be unsafe because it
assumes that nobody will ever add a field to Elf_Internal_Rel.  This
is of course unlikely, but note that somebody did add a field to
Elf_Internal_Shdr, so it is not impossible.

I think that better than this would be to change elf_swap_reloc_in to
accept a pointer to Elf_Internal_Rela, along with an appropriate
comment about this oddity.


I also don't see what the MIPS specific function reloc swap function
is going to do.  Assuming that Elf64_Mips_Internal_Rel is the same
size as Elf_Internal_Rel is not merely risky, it is actually certain
to be false on systems with a 64 bit long, such as the Alpha.  You can
make assumptions about the size of the external structs--those have
known formats.  However, you can not make assumptions about the size
of the internal structs.

Ian

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