Re: hppa dynamic linker fix for g++ 3.0

[Alan Modra <amodra at bigpond dot net dot au>]

On Sun, Jun 17, 2001 at 04:12:21PM -0700, Ulrich Drepper wrote:
> Matthew Wilcox <willy@paer.debian.org> writes:
> 
> > With gcc 3.0's new exception handling mechanism, relocations can now be
> > placed at addresses which are not aligned at a multiple of 4.  This patch
> > allows that to work.
> 
> You don't want to do it this way.  This is a horrible performance
> killer.  If you have unaligned relocations create a separate
> relocation type.  Look how other architectures (e.g. SPARC) do it.

Not true.  You may have missed the fact that byte stores are only used
when the address is unaligned.

This patch

Index: dl-machine.h
===================================================================
RCS file: /home/cvs/parisc/glibc/sysdeps/hppa/dl-machine.h,v
retrieving revision 1.40.2.2
diff -u -p -r1.40.2.2 dl-machine.h
--- dl-machine.h	2001/05/08 19:57:00	1.40.2.2
+++ dl-machine.h	2001/06/18 05:19:32
@@ -536,7 +536,16 @@ elf_machine_rela (struct link_map *map, 
       if (map == &_dl_rtld_map)
 	return;
 #endif
-      /* Otherwise, nothing more to do here. */
+      /* .eh_frame can have unaligned relocs.  */
+      if (__builtin_expect ((Elf32_Addr) reloc_addr & 3, 0))
+	{
+	  char *rel_addr = (char *) reloc_addr;
+	  rel_addr[0] = value >> 24;
+	  rel_addr[1] = value >> 16;
+	  rel_addr[2] = value >> 8;
+	  rel_addr[3] = value >> 0;
+	  return;
+	}
       break;
 
     case R_PARISC_PLABEL32:

costs exactly two instructions and one predicted not-taken branch in
a loop of 30 instructions traversed for the R_PARISC_DIR32 reloc.
ie. considerably less than 10% impact, and only for this reloc type.

Adding another reloc type will cost at least one branch in the loop
for a number of reloc types, and probably an instruction too.
Depending on the new reloc number, the mix of relocs in an object,
the compiler, the phase of moon etc., the impact of another reloc
type may be _worse_ than testing for an unaligned address.

-- 
Alan Modra

PS. willy, please don't post my patches without checking them when I
say "Something like this patch should..."  ;-)