Re: Bootstrapping hppa64 (phase 2): HP Linker problem

Re: Bootstrapping hppa64 (phase 2): HP Linker problem

[John David Anglin]

> > Here is a binutils fix for your problem.  The assembler now generates
> > the proper PCREL16F relocation when generating PA2.0W code.  I have
> > completed a bootstrap of GCC with the patch and will submit it to
> > binutils when the testsuite completes.

The enclosed patch corrects the relocation generated for format 1
load/store instructions under PA2.0W.  This caused a problem when
gas was used with the HP linker.  The patch now allows a 16-bit
offset with these insns.

Tested with binutils and hppa64-hp-hpux11.11 builds with no regressions.

Please install if ok.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2002-07-12  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* elf-hppa.h (elf_hppa_reloc_final_type): Use R_PARISC_PCREL16F as
	the final type for the e_fsel selector when generating PA2.0W code.
	(elf_hppa_relocate_insn): Provide support for PA2.0W 16-bit format 1
	relocations.

Index: elf-hppa.h
===================================================================
RCS file: /cvs/src/src/bfd/elf-hppa.h,v
retrieving revision 1.57
diff -u -3 -p -r1.57 elf-hppa.h
--- elf-hppa.h	16 Jun 2002 15:32:08 -0000	1.57
+++ elf-hppa.h	12 Jul 2002 17:43:53 -0000
@@ -811,7 +811,10 @@ elf_hppa_reloc_final_type (abfd, base_ty
 	      final_type = R_PARISC_PCREL14R;
 	      break;
 	    case e_fsel:
-	      final_type = R_PARISC_PCREL14F;
+	      if (bfd_get_mach (abfd) < 25)
+		final_type = R_PARISC_PCREL14F;
+	      else
+		final_type = R_PARISC_PCREL16F;
 	      break;
 	    default:
 	      return R_PARISC_NONE;
@@ -1609,8 +1612,7 @@ elf_hppa_final_link_relocate (rel, input
     case R_PARISC_NONE:
       break;
 
-    /* Basic function call support.  I'm not entirely sure if PCREL14F is
-       actually needed or even handled correctly.
+    /* Basic function call support.
 
        Note for a call to a function defined in another dynamic library
        we want to redirect the call to a stub.  */
@@ -2182,24 +2184,27 @@ elf_hppa_relocate_insn (insn, sym_value,
     case R_PARISC_DLTIND14R:
     case R_PARISC_DLTIND14F:
     case R_PARISC_LTOFF_FPTR14R:
-    case R_PARISC_LTOFF_FPTR16F:
     case R_PARISC_PCREL14R:
     case R_PARISC_PCREL14F:
-    case R_PARISC_PCREL16F:
     case R_PARISC_LTOFF_TP14R:
     case R_PARISC_LTOFF_TP14F:
-    case R_PARISC_LTOFF_TP16F:
     case R_PARISC_DPREL14R:
     case R_PARISC_DPREL14F:
-    case R_PARISC_GPREL16F:
     case R_PARISC_PLTOFF14R:
     case R_PARISC_PLTOFF14F:
-    case R_PARISC_PLTOFF16F:
     case R_PARISC_DIR14R:
     case R_PARISC_DIR14F:
+      return (insn & ~0x3fff) | low_sign_unext (sym_value, 14);
+
+    /* PA2.0W LDO and integer loads/stores with 16 bit displacements.  */
+    case R_PARISC_LTOFF_FPTR16F:
+    case R_PARISC_PCREL16F:
+    case R_PARISC_LTOFF_TP16F:
+    case R_PARISC_GPREL16F:
+    case R_PARISC_PLTOFF16F:
     case R_PARISC_DIR16F:
     case R_PARISC_LTOFF16F:
-      return (insn & ~0x3fff) | low_sign_unext (sym_value, 14);
+      return (insn & ~0xffff) | re_assemble_16 (sym_value);
 
     /* Doubleword loads and stores with a 14 bit displacement.  */
     case R_PARISC_DLTREL14DR:

Re: Bootstrapping hppa64 (phase 2): HP Linker problem

[Alan Modra]

On Fri, Jul 12, 2002 at 09:51:41PM -0400, John David Anglin wrote:
> Index: elf-hppa.h
> ===================================================================
> RCS file: /cvs/src/src/bfd/elf-hppa.h,v
> retrieving revision 1.57
> diff -u -3 -p -r1.57 elf-hppa.h
> --- elf-hppa.h	16 Jun 2002 15:32:08 -0000	1.57
> +++ elf-hppa.h	12 Jul 2002 17:43:53 -0000
> @@ -811,7 +811,10 @@ elf_hppa_reloc_final_type (abfd, base_ty
>  	      final_type = R_PARISC_PCREL14R;
>  	      break;
>  	    case e_fsel:
> -	      final_type = R_PARISC_PCREL14F;
> +	      if (bfd_get_mach (abfd) < 25)
> +		final_type = R_PARISC_PCREL14F;
> +	      else
> +		final_type = R_PARISC_PCREL16F;
>  	      break;
>  	    default:
>  	      return R_PARISC_NONE;

This will break elf32-hppa, won't it?  

	      if (bfd_get_arch_info (abfd)->bits_per_address != 32
		  bfd_get_mach (abfd) < 25)

Or you need to add support for all the 16 bit displacement insns to
elf32-hppa.c:final_link_relocate.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Bootstrapping hppa64 (phase 2): HP Linker problem

[Alan Modra]

On Mon, Jul 15, 2002 at 01:34:45PM +0930, Alan Modra wrote:
> 	      if (bfd_get_arch_info (abfd)->bits_per_address != 32
> 		  bfd_get_mach (abfd) < 25)

Oops, I mean
	      if (bfd_get_arch_info (abfd)->bits_per_address == 32
		  || bfd_get_mach (abfd) < 25)

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Bootstrapping hppa64 (phase 2): HP Linker problem

[John David Anglin]

> This will break elf32-hppa, won't it?  
> 
> 	      if (bfd_get_arch_info (abfd)->bits_per_address != 32
> 		  bfd_get_mach (abfd) < 25)
> 
> Or you need to add support for all the 16 bit displacement insns to
> elf32-hppa.c:final_link_relocate.

25 is PA2.0W code.  Gcc generates PA1.1 code as the default for hppa-linux
and optionally will generate PA2.0 code.  Thus, this only can occur if
a user writes his own PA2.0W assembler code.  I have done a complete
bootstrap of gcc using binutils with the patch installed on hppa-linux.

There is no benefit in adding the 16 bit displacement insns to
elf32-hppa.c:final_link_relocate at the moment since the W bit
isn't on in userland.

Currently, the assembler ignores the "W" in .level directives under
hppa-linux:

        .LEVEL 2.0W

asm.s: Assembler messages:
asm.s:1: Warning: rest of line ignored; first ignored character is `W'

Thus, it doesn't appear possible for mach to ever be 25 under hppa-linux.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Bootstrapping hppa64 (phase 2): HP Linker problem

[Alan Modra]

On Mon, Jul 15, 2002 at 12:48:29PM -0400, John David Anglin wrote:
> Thus, it doesn't appear possible for mach to ever be 25 under hppa-linux.

Oh, OK.  I'll commit your patch then.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre