Re: elf64-hppa branches

[Jeffrey A Law <law at cygnus dot com>]

  In message <Pine.LNX.4.21.0005300909580.15777-100000@front.linuxcare.com.au>y
ou write:
  > On Mon, 29 May 2000, Jeffrey A Law wrote:
  > 
  > >   In message <Pine.LNX.4.21.0005291236050.15777-100000@front.linuxcare.co
  > m.au>y
  > > ou write:
  > >   > Hi Jeff,
  > >   >   Two fixes for handling of hppa elf branch relocs.
  > > You need to explain what problem the changes are trying to fix.  Just
  > > assuming I understand what you're trying to do without any context is
  > > bad.  I might be able to guess, but I might guess wrong.  It's far better
  > > if you explain the problem you're trying to solve.
  > 
  > I thought it was clear enough from the change log,
It's far better to provide some explanation than to assume something is
obvious.

  > and it wasn't a case of
  > hitting a problem with the compiler/assembler/linker toolchain, but rather
  > just something I noticed looking at the code.
Got it.

  > 
  > Here's the ChangeLog again, perhaps you didn't see it first time around:
  >         * elf-hppa.h (elf_hppa_final_link_relocate): Use e_rsel field
  >         selector for R_PARISC_PCREL17R.  R_PARISC_DIR17R and
  >         R_PARISC_DIR17F are for absolute branches; Handle them as such.
  > 
  > The first change:
  > "Processor-Specific ELF Supplement for PA-RISC" says
  > Name     Value  Instruction format     Expression
  > PCREL17R  11    Branch External (19)   R(symbol - PC - 8 + addend)
  > 
  > so if ever a R_PARISC_PCREL17R reloc is generated, it should use the R'
  > field selector.
It seems so obvious now :-)


  > I can't see how this reloc is generated, or even makes
  > any sort of sense in code, so this change is just for consistency.
Right.  To the best of my knowledge there's no way/need to generate
PCREL17R, but yes, this change is OK.


  > The second change:
  > R_PARISC_DIR17R and R_PARISC_DIR17F are generated for instructions like
  > 
  >  be,n r'bar(%r1)
Right.

  > and all parisc branches store the displacement divided by four in the
  > instruction.
Right.

  > Without the patch, you'd get the raw displacement in the
  > instruction. 
Right.

  >  Also, I think absolute calls should go via a stub if they
  > are to a symbol in a dynamic library.
I strongly disagree.

First, we should never be using absolute calls.

Second, in the extremely rare case where an absolute call is useful it is
far more likely that what was intended was an absolute call to the final
target without a stub in the middle.  In fact, it is highly likely the
absolute call can't reach a local stub anyway.

All the changes except redirecting absolutes to local stubs is OK.

jeff