Como funciona um depurador no Linux?

Question

Como funciona um depurador no Linux? Como é que se "anexa" a um executável ou processo já em execução? Eu entendo que o compilador traduz o código para a linguagem de máquina, mas como o depurador 'sabe' o que está sendo anexado?

    

Answer 1

Existe uma chamada de sistema chamada ptrace . São necessários 4 parâmetros: a operação, o PID do processo de destino, um endereço na memória de processo de destino e um ponteiro de dados. A maneira como os últimos dois parâmetros são usados depende da operação.

Por exemplo, você pode anexar / desanexar seu depurador a um processo:

ptrace(PTRACE_ATTACH, pid, 0, 0);
...
ptrace(PTRACE_DETACH, pid, 0, 0);

Execução de etapa única:

ptrace(PTRACE_ATTACH, pid, 0, 0);
int status;
waitpid(pid, &status, WSTOPPED);
while (...) {
    ptrace(PTRACE_SINGLESTEP, pid, 0, 0);
    // give the user a chance to do something
}
ptrace(PTRACE_DETACH, pid, 0, 0);

Você também pode ler / gravar a memória do processo de destino com PTRACE_PEEKDATA e PTRACE_POKEDATA. Se você quiser ver um exemplo real, verifique o gdb .

    

Answer 2

but then how does debugger 'know' what it is being attached to?

de homem ptrace

The ptrace() system call provides a means by which one process (the "tracer") may observe and control the execution of another process (the "tracee"), and examine and change the tracee's memory and registers. It is primarily used to implement breakpoint debugging and system call tracing.

Como funcionam os depuradores Parte 1 de 3 é uma boa referência para usar ptrace , a chamada do sistema de depuração.

Muito brevemente, porque o gdb é uma fera complicada. No código-fonte do gdb a partir de hoje, as informações interessantes sobre o uso do ptrace do gdb são encontradas em target.h e inf-ptrace.c e pode facilmente ser perseguido de lá pelo ambicioso. Você verá que o gdb está usando ptrace , geralmente sem muita ambigüidade. Consulte os componentes da estrutura target_ops e encontre-os em inf-ptrace.c .

Do homem ptrace

>PTRACE_ATTACH
>       Attach to the process specified in pid, making it a tracee of the calling process.  The
>       tracee is sent a SIGSTOP, but will not necessarily have stopped by  the  completion  of
>       this  call;  use  waitpid(2)  to  wait  for the tracee to stop.  See the "Attaching and
>       detaching" subsection for additional information.  (addr and data are ignored.)

Então ptrace é usado, mas como ele sabe onde está tudo? Como o GDB obtém as informações necessárias para definir pontos de interrupção e ler dados? Sem DWARF ou algum formato de depuração menor, o gdb realmente não tem a menor ideia do que está fazendo ou de onde encontrar nada. Você ainda pode encontrá-los com o gdb pesquisando manualmente, porque as informações ainda estão lá na imagem do programa, mas o gdb não tem a menor idéia.

Abaixo está o Manual do Usuário do GDB - Stallman . O GDB, como acontece com todos os depuradores, usa um formato de depuração, normalmente DWARF em um sistema operacional razoável, para informações de símbolos referentes às funções e variáveis do programa.

In order to debug a program effectively, you need to generate debugging information when you compile it. This debugging information is stored in the object file; it describes the data type of each variable or function and the correspondence between source line numbers and addresses in the executable code. .... You will have the best debugging experience if you use the latest version of the DWARF debugging format that your compiler supports.

Informações sobre GDB, DWARF e PTRACE são extremamente fáceis de encontrar. E se você gosta de símbolos, informações sobre arquivos ELF também são fáceis de encontrar.