você pode usar vários segmentos para ptrace uma aplicação?

Question

Eu estou escrevendo um depurador orientada GUI que tem como alvo Linux principalmente, mas eu pretendo portas para outros sistemas operacionais no futuro. Porque o GUI deve ficar interativa em todos os momentos, eu tenho alguns tópicos lidar com as coisas diferentes.

Primeiramente eu tenho um thread "evento de depuração", que simplesmente loops de espera de waitpid para retorno e entrega os eventos recebidos para outros tópicos. Eu faço isso porque waitpid não tem um tempo limite, o que torna muito difícil integrá-lo com outros laço de eventos e manter as coisas sensíveis (waitpid pode pendurar indefinidamente!).

Esta estratégia tem funcionado maravilhosamente para o Linux constrói tão longe. Ultimamente eu tenho tentado fazer o meu fio depurador conscientes (como nos tópicos na aplicação depurado, não o próprio depurador).

Então eu definir as opções ptrace para acompanhar eventos de clones e olhar para um estado que tem o conjunto de 16-bit superior para PTRACE_EVENT_CLONE. Em seguida, use I PTRACE_GETEVENTMSG para obter o TID do novo segmento. Isso tudo funciona muito bem em minhas aplicações de equipamento de teste pequenas. Mas por alguma razão, ele está falhando quando eu colocar esse código no meu depurador real. (Eu recebo um "Sem tal processo" código de erro)

A única coisa que me ocorreu é que o Windows tem uma regra que apenas a discussão que anexado a um aplicativo pode ouvir eventos de depuração. Será ptrace de Linux têm uma limitação semelhante? Se assim for, por que meu código de trabalho para outros eventos de depuração?

EDIT:

Parece que nos apoios muito menos waitpid espera de um thread diferente, a página homem diz:

Antes de Linux 2.4, uma linha era apenas um caso especial de um processo, e como conseqüência fio não se poderia esperar no filhos de outro segmento, mesmo quando este último pertence à mesma rosca grupo. No entanto, prescreve POSIX tal funcionalidade, e desde Linux 2.4 um thread pode e, por padrão vai, espere em crianças de outros tópicos no mesmo grupo de discussão.

Assim, no máximo, esta é uma limitação ptrace.

Answer 1

Tanto quanto eu posso dizer, isso não é permitido. A tarefa não pode usar ptrace em uma tarefa que não tem anexado. Além disso, uma tarefa pode ser rastreada por no máximo uma outra tarefa, então você não pode simplesmente anexá-lo uma vez em cada thread. Eu acho que isso é porque quando um adidos tarefa para outra tarefa, a tarefa de rastreamento se torna o pai da tarefa atribuída, e cada tarefa pode ter apenas um pai.

Parece que o rastreamento multi-thread deve ser permitido porque os fios são parte do mesmo processo, mas a implementação-wise, não há realmente muita distinção entre segmentos e processos no kernel Linux. Um fio é apenas uma tarefa que passa a compartilhar mais de seus recursos com outra tarefa.

Se você estiver interessado, você pode navegar na código fonte para ptrace no kernel. Especificamente olhar para ptrace_check_attach , que é chamado por sys_ptrace para a maioria solicitações de. Ele retorna -ESRCH (soa como o código de erro que você está recebendo) se o pai a tarefa alvo do não é a tarefa atual.

Answer 2

Eu tive o mesmo problema (além de muitos outros!) Ao implementar a parte específica do Linux do Maxine VM depurador . Você está correto em sua suposição de que apenas uma thread no depurador pode usar ptrace para controlar o depurado. Nós conseguimos isso através de todas as chamadas para ptrace em um segmento dedicado. Você pode achar que é útil olhar para o LinuxTask.java, arquivos linuxTask.h e linuxTask.c nas fontes de Maxine disponíveis em kenai.com/projects/maxine/sources/maxine/show