Como visto na secção 4.7.2, um serviço para a depuração de processos distribuídos foi desenvolvido no primeiro protótipo da DAMS. O trabalho na área da depuração deste tipo de sistemas foi prosseguido no contexto de outro trabalho de doutoramento [85]). No en- tanto, um dos primeiros protótipos desenvolvidos de um depurador distribuído foi baseado no primeiro modelo DAMS, tendo essa experimentação contribuído por um lado para validar parcialmente os conceitos do modelo DAMS e, por outro lado, para motivar a evolução do modelo.
O serviço para depuração ou debugging aqui apresentado baseia-se na implementação efectuada para a ferramenta PDBG, sobre o primeiro protótipo DAMS. Apresentam-se aqui as operações equivalentes às existentes nesses sistemas e que demonstraram a sua utilidade em várias situações [84, 23, 22, 70]. Note-se que na nova DAMS, existe uma clara separa- ção entre a infraestrutura e os serviços; e que, do ponto de vista da infraestrutura, o serviço central e os vários serviços locais a cada nó não têm suporte diferenciado. Assim, também para as ferramentas, a utilização destas funcionalidades pode ser suportada por um serviço central, ou também utilizando as funcionalidades oferecidas directamente pelos vários ser- viços locais. O serviço central não necessita de ser o único ponto de acesso, em particular
6.4. Controlo para depuração 155
quando apenas um processo está sob controlo da ferramenta.
A implementação de um sistema equivalente ao desenvolvido no primeiro protótipo divide-se em dois tipos de serviços:
• Um primeiro, o dbg-local, que permite controlar e inspeccionar os processos locais a cada nó, por utilização de um depurador sequencial (por exemplo o gdb). Este trata-se do apresentado na secção 4.7.2 e desempenha o papel antes desempenhado pelo driver em cada nó no primeiro protótipo. Para tal, um processo gdb é lançado para cada processo que se pretenda sob o controlo deste serviço.
• Um segundo serviço, central, o dbg que, utilizando os anteriores, permite um único ponto de acesso a todos os processos distribuídos no sistema. Este serve também de concentrador de todas as notificações vindas dos vários dbg-local, para facilitar a subscrição pelas ferramentas de todos os eventos gerados no sistema. Este serviço desempenha o papel antes suportado pelo SMod do serviço, no primeiro protótipo.
6.4.1
Serviço para depuração
A implementação do serviço de controlo apresentado na secção 4.7.2 e seguindo o protó- tipo antes desenvolvido, é suportada pela utilização de um programa para depuração (no caso foi usado o gdb) como controlador do processo alvo. A ligação entre o serviço e esse pro- grama, é efectuada pela interface por este oferecida, sendo-lhe enviados comandos (texto) e processando as respostas recebidas, do mesmo modo (fig. 6.9). Esta ligação é suportada por uma ligação bidireccional (input/output) sobre um “pseudo-terminal”, que permite a interac- ção do serviço com os respectivos canais de entrada e saída standard do gdb. Cada comando suportado pelo serviço é traduzido no respectivo comando do gdb.
O sistema de notificações é oferecido sobre o mecanismo de canais de eventos. Cada ser- viço oferece um novo canal de eventos onde anuncia alterações na execução dos processos: de cada vez que um processo sobre o seu controlo pára (breakpoint por exemplo) ou retoma a execução (continue por exemplo), um evento descrevendo o acontecimento e o processo envolvido é criado. Uma ferramenta pode estar atenda a estes acontecimentos subscrevendo directamente os canais dos serviços que lhe interessam.
proc. pty gdb ferramentas ou outros serviços dbg−local
Figura 6.9: Um serviço para depuração usando ogdb
respectivo servidor do serviço, da seguinte forma:
dbgAttach(servID, long pid)
permite a ligação do serviço a um processo específico. Corresponde a lançar um pro- cesso gdb sob o controlo do servidor e efectuar o respectivo comando “attach” ao pid indicado;
dbgDetach(servID, long pid)
permite libertar o processo indicado do controlo do serviço. Corresponde a efectuar o “detach” e a terminar o processo do gdb respectivo;
dbgStop(servID, lond pid)
neste caso é enviado ao processo indicado, um sinal para parar (SIGSTOP do sistema de operação);
dbgStep(servID, lond pid) envia ao gdb o comando “step”;
dbgContinue(servID, lond pid) envia ao gdb o comando “continue”;
dbgSetBreakLine(servID, long pid, char *fname, long line)
corresponde a enviar ao gdb o comando “break”, indicando o ficheiro fonte e linha onde se pretende a paragem;
dbgDelBreak(servID, long pid, char *fname, long line )
corresponde a enviar o comando “clear” ao respectivo gdb, para remover o ponto de paragem indicado;
6.4. Controlo para depuração 157
dbgGetValue(servID, long pid, char *var , char *buf, long bufsz)
envia ao respectivo gdb o comando “print” onde o argumento é o indicado pela cadeia var, sendo a resposta devolvida no vector buf;
dbgSetValue(servID, long pid, char *var, char *buf, long bufsz)
corresponde a enviar o comando “set” ao gdb, com a variável e respectivo valor dado pelos restantes argumentos.
6.4.2
Serviço central para depuração
O serviço para depuração de aplicações distribuídas, desenvolvido no primeiro protótipo da DAMS, já antes referido, permite a qualquer ferramenta controlar um ou vários processos da aplicação. A arquitectura deste serviço, como é de esperar, reflecte o modelo anterior, apresentado na secção 4.2. Neste, o SMod suporta os diversos comandos disponíveis aos clientes, encaminhando-os para o respectivo driver do serviço, com base no identificador do processo alvo. Este mantém informação para cada processo controlado (attached), sobre sua localização no sistema, para poder encaminhar cada pedido usando o LM localizado no mesmo nó que o processo alvo, fazendo chegar cada comando ao driver devido, como descrito na referida secção. Esta arquitectura é semelhante à de outros sistemas [65, 110], onde também um servidor central coordena representantes remotos em cada máquina, que realmente interactuam com os processos da aplicação.
Dispõe-se assim, de forma transparente e independente das particularidades dos depura- dores usados em cada máquina, das funcionalidades para parar, continuar, colocar/remover pontos de paragem, etc. em qualquer/s processo/s da aplicação. Cada driver corresponde ao serviço de controlo para depuração apresentado no secção 6.4.1, na qual a descrição anterior se baseou.
As operações então suportadas agora pelo serviço central, são as mesmas do antigo ser- viço no primeiro protótipo da DAMS, permitindo a compatibilidade funcional nas ferramen- tas anteriores. Estes comandos correspondem aos do serviço dbg-local, antes apresentado, mas onde o identificador do processo alvo referencia, agora, qualquer processo na máquina virtual da DAMS, mais as seguintes operações:
dbgLocalID dbgAddHost(servID, hostID)
permite requerer que o respectivo serviço local (dbg-local) seja lançado pelo núcleo no nó indicado, passando a ser possível controlar os processos nessa máquina
dbgLocalID dbgDelHost(servID, hostID)
liberta o serviço local no nó referido, libertando (detach) todos os processos sob o seu controlo.
dbgProcessNotification(servID, event)
verifica se existe alguma notificação pendente, recebendo-a no argumento indicado (estas indicam as alterações ao estado dos processos sob depuração).
A utilização do novo modelo da DAMS em substituição do primeiro protótipo, permite mostrar as suas vantagens acrescidas de uma infraestrutura flexível, ao ser capaz de suportar as mesmas funcionalidades do modelo anterior. O serviço dbg, a usar pelas ferramentas, serve de intermediário entre as ferramentas e os serviços locais anteriores, permitindo ofere- cer funcionalidades de âmbito geral ao sistema distribuído, como as existentes no primeiro protótipo da DAMS. Este terá de ser capaz de identificar qualquer processo no sistema alvo e encaminhar os comandos para controlo de cada processo para o serviço local respectivo. Estes identificadores são conseguidos pela junção do identificador local do processo, como é reconhecido pela instância do serviço local no nó respectivo, com o identificador desse serviço local. As listas de processos em cada nó podem ser obtidas por interacção com o respectivo núcleo DAMS.
A figura 6.10 apresenta um esquema da arquitectura do sistema sobre a nova DAMS. O serviço centralizador cria também o seu próprio canal de eventos que as ferramentas clientes podem subescrever. Este serviço, por seu lado, torna-se subscritor de todos os canais de eventos associados aos vários serviços remotos, tornando-se um concentrador de todas as notificações no sistema. Cada ferramenta pode, subscrevendo apenas o canal de eventos oferecido pelo serviço para depuração central, ser notificada de todas as alterações no estado dos processos sob controlo. É assim possível, neste novo sistema, dispensar a primitiva que antes existia para testar a chegada de notificações (dbgProcessNotification) e, em alternativa, usar-se apenas o mecanismo de canais de eventos da nova DAMS.
6.5. Controlo dinâmico (steering) 159