diff options
| -rw-r--r-- | gdb/ChangeLog | 6 | ||||
| -rw-r--r-- | gdb/arm-linux-nat.c | 126 | ||||
| -rw-r--r-- | gdb/arm-linux-tdep.c | 126 |
3 files changed, 132 insertions, 126 deletions
diff --git a/gdb/ChangeLog b/gdb/ChangeLog index c8bda64..c616d90 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,9 @@ +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. + 2000-04-10 Fernando Nasser <fnasser@cygnus.com> From 2000-04-10 Rodney Brown <rdb@redhat.com>: 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) { diff --git a/gdb/arm-linux-tdep.c b/gdb/arm-linux-tdep.c index 8a575a4..667fd0b 100644 --- a/gdb/arm-linux-tdep.c +++ b/gdb/arm-linux-tdep.c @@ -221,6 +221,132 @@ arm_linux_push_arguments (int nargs, value_ptr * args, CORE_ADDR sp, return sp; } +/* + 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; +} + void _initialize_arm_linux_tdep (void) { |