Arquitectura de la herramienta GDB

GDB es una herramienta de monitorizaci´on que se puede obtener y utilizar libremente (software libre). A parte de la monitorizaci´on local, esta herramienta tambi´en ofrece la monitorizaci´on remota, la cual est´a pensada para los casos en que se necesite monitorizar un programa situado en una m´aquina remota y no se puede utilizar directamente la herramienta GDB como se har´ıa en el caso local. Esta circunstancia puede ser debida a que en esta m´aquina remota no se permite la interacci´on desde la maquina local del usuario (por ejemplo no se pueden abrir terminales remotos, como ssh) o no posee suficientes recursos (por ejemplo, poca memoria) para ejecutarla.

Para poder realizar la ejecuci´on remota, la arquitectura de GDB se basa en la utilizaci´on de dos procesos: Un proceso, denominado gdb, que se ejecuta en la maquina local del usuario y un proceso demonio, llamado gdbserver, que se ejecuta en la m´aquina remota donde se va ha monitorizar el proceso del usuario. El proceso gdb recoge las peticiones

2.4. Arquitectura b´asica de las herramientas de monitorizaci´on 27 del usuario, a trav´es de unos comandos propios que se introducen por medio de una consola de texto, las env´ıa al demonio gdbserver y recoge sus repuestas para mostrarlas al usuario. Por su parte el demonio gdbserver, recibe las peticiones provenientes del procesogdb, realiza las acciones de monitorizaci´on sobre el proceso a monitorizar y env´ıa el resultado de estas acciones a dicho proceso gdb. Por lo tanto, en la arquitectura de GDB, el demonio gdbserver es su componente remoto y el proceso gdb su componente local.

Para ejecutar correctamente estos dos componentes de la herramienta GDB [25] se han de realizar los siguientes pasos:

1. Ejecutar el demonio gdbserver en la m´aquina remota: Para ello se utiliza el comando cuya sintaxis es la siguiente:

gdbserver comunicaci´on dir nombre ejecutable [argumentos ejecutable]

Donde:

comunicaci´on: Argumento que define el tipo de conexi´on con el proceso gdb.

Se permiten diversos tipos de conexi´on, entre las cuales destacan el protocolo serie (RS-232) o el TCP/IP (Internet). Para este ultimo protocolo (que es el m´as habitual) se utiliza el siguiente formatohost:puerto, donde host define el nombre de la m´aquina donde se ejecuta el demonio gdbserver y port define un puerto de comunicaciones libre en dicha m´aquina (y que utilizar´a dicho demonio). Como el host siempre es la m´aquina donde se ejecuta el propio gdbserver, esta parte del argumento se puede obviar y solo indicar la parte del puerto de comunicaciones, en este caso, este argumento tendr´ıa el formato:”

:port”.

dir nombre ejecutable: Argumento que indica la direcci´on y el nombre del ejecutable del proceso a monitorizar en la m´aquina remota. Como puede observarse, este proceso tiene que estar situado en la m´aquina remota antes de que puede ser monitorizado por el demonio gdbeserver.

argumentos ejecutable: Define los posibles argumentos del proceso a monito-rizar.

28 2. Estado del arte GDB tambi´en permite que el demonio gdbserver se adjunte a un proceso que ya esta en ejecuci´on en la m´aquina remota. Para ello se utiliza el siguiente comando:

gdbserver –attach comunicaci´on pid, donde pid es el identificador del proceso que se quiere monitorizar y que es dado por el Sistema Operativo. Por lo tanto, antes de poder realizar la operativa de adjuntarse a un proceso, se ha de obtener este pid. La manera mas habitual de hacerlo es conectarse a la maquina remota, mediante un terminal remoto y efectuar la o las llamadas al Sistema operativo que le proporcionen dicho pid del proceso. Por ejemplo, si el sistema operativo de la m´aquina remota es Linux, se puede ejecutar un terminal remoto en ella (con ssh) y ejecutar el comando ps. Tambi´en se puede usar la llamada al sistema pidof, la cual devuelve el pid del nombre del proceso pasado como su argumento. Para este ultimo m´etodo gdbserver se ejecutar´ıa de la siguiente forma: gdbserver - -attach comunicaci´on ’pidof nombre proceso monitorizar’.

2. Conectar el componente local de GDB al demonio gdbserver: Para ello se ejecuta, en la maquina local, el proceso gdb, pas´andole como argumento el ejecutable del proceso que se quiere monitorizar (igual que para una monitorizaci´on local). Una vez en la consola del proceso gdb, se ejecuta el siguiente comando propio de la herramienta:target remote comunicaci´on. En el caso de una conexi´on TCP/IP, este argumentocomunicaci´on tendr´a el siguiente formatohost gdbserver:port gdbserver, donde host gdbserver es el nombre de la m´aquina remota donde se ejecuta el demonio gdbserver y port gdbserver es el puerto de comunicaciones que utiliza dicho demonio.

Para finalizar una monitorizaci´on remota se pueden utilizar los siguientes comandos de la herramienta: detach, se desconecta del demonio gdbserver y finaliza la ejecuci´on de este ydisconnect realiza la misma funci´on quedetach, pero sin finalizar la ejecuci´on del demonio gdbserver

A continuaci´on se muestra en ejemplo de los pasos explicados anteriormente:

Se desea monitorizar el proceso user exec situado en el directorio /home/user/ de la maquina host1 con la herramienta GDB. Para ello, primero se escoge un puerto de comunicaciones libre en esta m´aquina, para este caso el 2000 y a continuaci´on se ejecuta en ella el demonio gdbserver. Si se utiliza la herramienta de conexi´on remota ssh para ejecutarlo desde la m´aquina local del usuario, el comando que lo realizar´ıa seria:

2.4. Arquitectura b´asica de las herramientas de monitorizaci´on 29 maquina local user > ssh user@host1 gdbserver :2000 /home/user/user exec Una vez el demoniogdbeserver est´a en ejecuci´on en la m´aquina remota, el procesogdb ya se puede conectar a el. Para ello, en la consola de este proceso se introducir´a el siguiente comando:

consola gdb> target remote host1:2000

Como ultimo apunte a esta herramienta se puede comentar que el ejecutable que se le pasa al demonio gdbserver no es necesario que contenga la tabla de s´ımbolos (informaci´on de monitorizaci´on), mientras que el que se le pasa al proceso gdb si que la he de tener. Esto implica que el ejecutable que monitorizar´a gdbserver ocupar´a menos espacio (consumir´a menos recursos) que el del GDB local.