Move arm_skip_solib_resolver from arm-linux-nat.c to arm-linux-tdep.c.

2000-04-10  Philip Blundell <philb@gnu.org>

	* arm-linux-nat.c (arm_skip_solib_resolver): Remove and move to
	arm-linux-tdep.c.
	* arm-linux-tdep.c (arm_skip_solib_resolver): New.

1 files changed, 0 insertions, 126 deletions

diff --git a/gdb/arm-linux-nat.c b/gdb/arm-linux-nat.c
index b8d30e5..aa2eb28 100644
--- a/gdb/arm-linux-nat.c
+++ b/gdb/arm-linux-nat.c
@@ -322,132 +322,6 @@ store_inferior_registers (int regno)
     store_fpregs ();
 }
 
-/*
-   Dynamic Linking on ARM Linux
-   ----------------------------
-
-   Note: PLT = procedure linkage table
-   GOT = global offset table
-
-   As much as possible, ELF dynamic linking defers the resolution of
-   jump/call addresses until the last minute. The technique used is
-   inspired by the i386 ELF design, and is based on the following
-   constraints.
-
-   1) The calling technique should not force a change in the assembly
-   code produced for apps; it MAY cause changes in the way assembly
-   code is produced for position independent code (i.e. shared
-   libraries).
-
-   2) The technique must be such that all executable areas must not be
-   modified; and any modified areas must not be executed.
-
-   To do this, there are three steps involved in a typical jump:
-
-   1) in the code
-   2) through the PLT
-   3) using a pointer from the GOT
-
-   When the executable or library is first loaded, each GOT entry is
-   initialized to point to the code which implements dynamic name
-   resolution and code finding.  This is normally a function in the
-   program interpreter (on ARM Linux this is usually ld-linux.so.2,
-   but it does not have to be).  On the first invocation, the function
-   is located and the GOT entry is replaced with the real function
-   address.  Subsequent calls go through steps 1, 2 and 3 and end up
-   calling the real code.
-
-   1) In the code: 
-
-   b    function_call
-   bl   function_call
-
-   This is typical ARM code using the 26 bit relative branch or branch
-   and link instructions.  The target of the instruction
-   (function_call is usually the address of the function to be called.
-   In position independent code, the target of the instruction is
-   actually an entry in the PLT when calling functions in a shared
-   library.  Note that this call is identical to a normal function
-   call, only the target differs.
-
-   2) In the PLT:
-
-   The PLT is a synthetic area, created by the linker. It exists in
-   both executables and libraries. It is an array of stubs, one per
-   imported function call. It looks like this:
-
-   PLT[0]:
-   str     lr, [sp, #-4]!       @push the return address (lr)
-   ldr     lr, [pc, #16]   @load from 6 words ahead
-   add     lr, pc, lr      @form an address for GOT[0]
-   ldr     pc, [lr, #8]!   @jump to the contents of that addr
-
-   The return address (lr) is pushed on the stack and used for
-   calculations.  The load on the second line loads the lr with
-   &GOT[3] - . - 20.  The addition on the third leaves:
-
-   lr = (&GOT[3] - . - 20) + (. + 8)
-   lr = (&GOT[3] - 12)
-   lr = &GOT[0]
-
-   On the fourth line, the pc and lr are both updated, so that:
-
-   pc = GOT[2]
-   lr = &GOT[0] + 8
-   = &GOT[2]
-
-   NOTE: PLT[0] borrows an offset .word from PLT[1]. This is a little
-   "tight", but allows us to keep all the PLT entries the same size.
-
-   PLT[n+1]:
-   ldr     ip, [pc, #4]    @load offset from gotoff
-   add     ip, pc, ip      @add the offset to the pc
-   ldr     pc, [ip]        @jump to that address
-   gotoff: .word   GOT[n+3] - .
-
-   The load on the first line, gets an offset from the fourth word of
-   the PLT entry.  The add on the second line makes ip = &GOT[n+3],
-   which contains either a pointer to PLT[0] (the fixup trampoline) or
-   a pointer to the actual code.
-
-   3) In the GOT:
-
-   The GOT contains helper pointers for both code (PLT) fixups and
-   data fixups.  The first 3 entries of the GOT are special. The next
-   M entries (where M is the number of entries in the PLT) belong to
-   the PLT fixups. The next D (all remaining) entries belong to
-   various data fixups. The actual size of the GOT is 3 + M + D.
-
-   The GOT is also a synthetic area, created by the linker. It exists
-   in both executables and libraries.  When the GOT is first
-   initialized , all the GOT entries relating to PLT fixups are
-   pointing to code back at PLT[0].
-
-   The special entries in the GOT are:
-
-   GOT[0] = linked list pointer used by the dynamic loader
-   GOT[1] = pointer to the reloc table for this module
-   GOT[2] = pointer to the fixup/resolver code
-
-   The first invocation of function call comes through and uses the
-   fixup/resolver code.  On the entry to the fixup/resolver code:
-
-   ip = &GOT[n+3]
-   lr = &GOT[2]
-   stack[0] = return address (lr) of the function call
-   [r0, r1, r2, r3] are still the arguments to the function call
-
-   This is enough information for the fixup/resolver code to work
-   with.  Before the fixup/resolver code returns, it actually calls
-   the requested function and repairs &GOT[n+3].  */
-
-CORE_ADDR
-arm_skip_solib_resolver (CORE_ADDR pc)
-{
-  /* FIXME */
-  return 0;
-}
-
 int
 arm_linux_register_u_addr (int blockend, int regnum)
 {