Na verdade, o comportamento que você está descrevendo vem do comportamento normal das seções GOT / PLT. Eles são usados ​​para vincular dinamicamente as chamadas do programa a funções de bibliotecas compartilhadas em tempo de execução.

Na verdade, uma biblioteca compartilhada pode ser carregada em qualquer lugar na memória do processo, não há como prever estaticamente onde ela será Aparecer. Assim, o GOT / PLT carrega o endereço da função de cada biblioteca dinamicamente em tempo de execução e armazena em cache para uso posterior.

A forma como funciona é bastante simples, o PLT ( Tabela de ligação de procedimentos ) é apenas um monte de pequenos dispositivos de código (um para cada função de biblioteca chamada no programa, mais um código genérico localizado no início da seção PLT).

E o GOT ( Global Offset Table ) é apenas uma tabela usada para armazenar (e armazenar em cache) os endereços das funções da biblioteca.

No início, o GOT é definido como zero porque nenhum endereço de função foi resolvido ainda. O GOT fica preenchido ao longo do programa é executado e chama novas funções (algumas funções podem ser chamadas apenas raramente e seus endereços podem ser raramente preenchidos no GOT).

Quando uma função de biblioteca é chamada de programa counter vai para o PLT (veja a figura abaixo) e executa o código escrito especificamente para esta função (cada um dos dispositivos de código tem seus próprios deslocamentos para obter o endereço adequado do GOT). Mas, a princípio, o GOT contém apenas zeros, então você precisa inicializá-lo.

Para inicializá-lo, você pula no início do PLT e encontra o endereço da função da biblioteca que o programa deseja chamar . Você executa este código e, em seguida, escreve o endereço da função no GOT.

Depois de armazenar em cache o endereço do , você não precisa mais recalcular o endereço se chamar sua função e pular diretamente para ela (como na imagem a seguir).

No caso do ARM, você tem dois tipos de esquemas GOT / PLT:

• PLTs diretos
• PLTs indiretos

No seu caso, este é um PLT direto (mas parece ser um código bem antigo, eu suspeito de um compilador antigo ou algo assim , porque é melhor que os novos usem ip no lugar de lr para isso).

 ; seção: .plt; função: function_1708 em 0x1708 - 0x17180x1708: 04 e0 2d e5 str lr, [sp, # -4]! <-- Salve lr na pilha0x170c: 04 e0 9f e5 ldr lr, [pc, # 4] <-- Obtenha um ponto de referência na memória0x1710: 0e e0 8f e0 add lr, pc, lr <-- Compensação de carga para o próximo passo0x1714: 08 f0 seja e5 ldr pc, [lr, # 8]! <-- Pule para a próxima etapa  

Observe que a PLT é uma seção estática, portanto, o 0x170c sempre permanecerá o mesmo (e, portanto, o pc será sempre carregado com o mesmo valor em 0x170c).

Referências

• Código Independente de Posição (PIC) em bibliotecas compartilhadas, por Eli Bendersky.

• Montador ARM em Raspberry Pi - Capítulo 27, por Roger Ferrer Ibáñez.

• Conjunto de ferramentas ARM FDPIC, bibliotecas kernel & para Cortex-M & Cortex-R.

Embora a outra resposta não esteja errada, ela não cobre o verdadeiro problema: como é que chamar um endereço zero não leva a um travamento?

AFAIK, não há um padrão oficial ou documentação completa para isso, mas de fato as primeiras entradas do GOT são especiais / reservadas e são usadas pelo carregador / vinculador dinâmico (às vezes também chamado de interpretador ) para seus próprios fins:

• GOT [0] aponta para o símbolo _DYNAMIC do módulo atual que é o início da lista de tags ( Elf32_Dyn entradas) com as várias informações necessárias para a resolução adequada de símbolos dinâmicos. Veja a especificação ELF.

• GOT [1] é preenchido em tempo de execução com o ponteiro para a estrutura link_map contendo a lista de todas as imagens dinâmicas presentes no processo. Esta lista reside no vinculador dinâmico ( ld.so em sistemas Linux e vinculador binário no Android).

• GOT [2] também é preenchido pelo vinculador dinâmico e aponta para a função de resolvedor ( _dl_runtime_resolve em glibc, não tenho certeza no Android).

O snippet que você citou é o stub do resolvedor , que é chamado na primeira chamada de um símbolo externo (você pode ver que todas as entradas GOT são inicializadas para seu endereço, 1708 ). Ele busca GOT [2] e salta para ele, que deve terminar no vinculador dinâmico, que iria procurar o símbolo, corrigir a entrada GOT e pular para a função como a última etapa.

Como eu disse, não há documentos oficiais (AFAIK) sobre isso, apenas partes aleatórias da especificação ELF ABI, código-fonte glibc e várias postagens de blog. Eu sugeriria que você percorresse este código em um depurador para ver o que realmente acontece e compará-lo com o código-fonte. Além dos links de @ perror , encontrei este post que explica algumas das entradas GOT reservadas (embora para Linux x64 e não para Android ARM).