This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Bootstrapping hppa64 (phase 2): HP Linker problem
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: sje at cup dot hp dot com (Steve Ellcey)
- Cc: neil at daikokuya dot co dot uk, gcc at gcc dot gnu dot org, law at redhat dot com, zack at codesourcery dot com
- Date: Fri, 12 Jul 2002 15:13:11 -0400 (EDT)
- Subject: Re: Bootstrapping hppa64 (phase 2): HP Linker problem
> I am not sure how wide spread the problem is, it is certainly the case
> that our prebuilt 3.0.2 GCC will not bootstrap the latest GCC, I suspect
> that there might be a problem using any hppa64 3.0* GCC to bootstrap the
> latest sources. I think David Anglin uses a newer GCC (or HP C?) to
> bootstrap his hppa64 GCC. Also, we didn't see this problem until
> recently when we updated our sources so I don't think there is a problem
> using 3.0.2 GCC to build itself or 3.1 GCC.
This is something that I don't want to help in supporting. I don't have
a copy of the HP 3.0.2 release. There are similar issues with the debian
3.0.4 base compiler for hppa-linux. When a vendor applies patches to a
distribution for their own purposes, then it's not possible for the
volunteer community to support the result. I have tried to resolve
the build issues using the current GCC release version and with the
HP bundled and ansi compilers. As far as I am aware, 3.1.1 will build
without a problem using GNU as and ld. The build matrix is just too
extensive to test all the combinations and permutations of assemblers,
linkers, debuggers ...
My personal opinion is that the recommended linker should be the GNU
linker. It is much easier to debug problems using it, the feature set
is more compatible, and finally the debugging output currently produced
by GCC isn't compatible with that used by the HP tools. In the 32-bit
case, the limitations of the som linker are the cause of many implementation
problems. If you compare testsuite results, you will see that hppa-linux
port using the gnu linker is in better shape than the hpux port.
The reason why $PIC_pcrel is used instead of the symbol difference
used with SOM, is the assembler doesn't support performing the difference
of two symbols when one of the symbols isn't in the current function.
This is required, so the code to generate a pc relative relocation
is output instead.
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.
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: