RE: [Linux-ia64] ld failure

["Saxena, Sunil" <sunil.saxena@intel.com>]

Hi Jim,

Here are the relocations that have been agreed in the ABI.  You can talk to
Ulrich on details:

Name         Value     Instruction Format     Expression
------------------------------------------------------------------
PCREL60B     0x48      br long (X3, X4)       symbol + addend - IP
PCREL21BI    0x79      br (B1, B2, B3, B6)    symbol + addend - IP
PCREL22      0x7A      add imm22 (A5)         symbol + addend - IP
PCREL64I     0x7B      mov imm64 (I18/X2)     symbol + addend - IP

The PCREL21BI relocation works just like PCREL21B, but it marks a call for
which gp has not been saved, thus requiring that the target reside within
the same load module as the call. We need it for cases where we choose to
bind a symbol locally, optimizing the call sequence, but where we don't want
to, or can't, mark the symbol "protected" or "hidden."

The PCREL22 and PCREL64I relocations are needed for pc-relative references
to constants and literals. PCREL64I is also needed (internally to the
linker) for long branch stubs.

Regarding the brl emulation, we should have a patch ready for Trillian work
next week.

Thanks
Sunil

-----Original Message-----
From: Jim Wilson [mailto:wilson@cygnus.com]
Sent: Wednesday, April 26, 2000 11:58 AM
To: Christoph Rohland
Cc: linux-ia64@linuxia64.org
Subject: Re: [Linux-ia64] ld failure 


There is an optional patch available for the current stable toolchain that
fixes this.  There are a few details to work out.
1) It uses the linker relaxation support, which isn't the default.  So for
   the moment the user needs to manually specify -Wl,-relax on the gcc
command
   line.
2) It uses the brl instruction which the Itanium does not implement.  The
   kernel needs to emulate the instruction.  I know that people are working
on
   this kernel support, but I don't know if it is available yet.  So you
will
   be able to link the program, but you may not be able to run it.
3) The ABI does not define relocations for brl yet, so we invented our own.
   These will have to change when standard relocations are specified, which
   may result in a user visble ABI change.

These problems should hopefully all be resolved by the time of the next
toolchain release, which is tentatively scheduled for late June.

Looking at this, I see that some rearrangement of code in our startup files
might help delay the point at which a program becomes too big.  I'll make a
note to myself to look into that.