• 1. A través de registros dedicados en los que se almacena la dirección del punto de interrupción y después se comprueba si el contador de programa coincide con el valor de alguno de los registros.
• 2. Cuando se está utilizando un emulador que incluye circuitos que monitorizan las líneas de direcciones de salida del procesador y detienen la ejecución si coinciden con la dirección de un punto de interrupción.
• 3. Cuando el objetivo tiene la habilidad propia de establecer breakpoints, como por ejemplo, un monitor ROM que es capaz de establecer sus propios breakpoints software, que aunque no sean breakpoints hardware literales, para GDB si lo son.

Como los breakpoints hardware no están siempre disponibles, se necesita un método para establecer breakpoints software, a grandes rasgos:

• 1. GDB guarda internamente la instrucción original en la dirección del punto de interrupción y la reemplaza por una interrupción (por ejemplo, INT3 en x86) o una instrucción inválida (por ejemplo, una división ilegal) que cause una excepción.
• 2. GDB recibe la señal de que ha ocurrido una excepción (SIGCHLD) y comprueba si la dirección del contador de programa está en la lista de breakpoints, si es así, se trata de un punto de interrupción, si no, es un fallo producido por el programa.
• 3. El depurador se encuentra detenido en el punto de interrupción y el usuario realiza las operaciones que considere necesarias.
• 4. Para reanudar la ejecución, GDB recupera la instrucción original, ejecuta la instrucción en modo single-step, vuelve a introducir la interrupción y, por último, continúa con la ejecución normal.

GDB proporciona otra funcionalidad además de los breakpoints. Echar un ojo a la documentación.



The post Empezando a depurar codigo (II) – Breakpoints appeared first on S3lab.

Existen varias formas de lidiar con los errores, probablemente el método más utilizado es añadir llamadas a la función print() (en todas sus variantes) en distintas partes del código para poder seguir la ejecución del programa y comprobar que valores toman las variables en determinados momentos. Pero también existen herramientas conocidas como depuradores que, a pesar de que a personas como Linus Torvalds no le entusiasmen demasiado, ofrecen funcionalidad útil para combatir errores complejos, y no solo eso, sino que también son una herramienta potente en el análisis de programas con distintos objetivos. En sistemas Unix, el depurador por excelencia es GDB, que permite hacer cuatro cosas principalmente: iniciar un programa especificando parámetros que puedan afectar su comportamiento, detener un programa en determinadas condiciones y momentos, inspeccionar que está ocurriendo dentro del programa, y modificar distintos valores del programa para observar como afecta a su comportamiento. Pero, ¿como puede un depurador como GDB tener control sobre otro proceso?

La funcionalidad de observar y controlar la ejecución de otro proceso se proporciona mediante la llamada al sistema ptrace(), pero para ello primero es necesario adjuntar el proceso «rastreador» (el depurador GDB en este caso) al proceso «rastreado«. A grandes rasgos, la primera forma de conseguirlo es ejecutando el programa desde GDB, de forma que se haga un fork() del proceso y se establezca una relación directa padre-hijo. Por otra parte, también existe la posibilidad de asumir el rol de proceso padre y adjuntarse a un proceso en ejecución mediante la operación PTRACE_ATTACH. Las principales operaciones (entre otras) que ptrace permite realizar sobre el proceso rastreado son:

• Leer contenidos de la memoria (PTRACE_PEEKTEXT, PTRACE_PEEKDATA, PTRACE_PEEKUSER) y escribir en memoria (PTRACE_POKETEXT, PTRACE_POKEDATA, PTRACE_POKEUSER).
• Obtener/leer contenidos en los registros (PTRACE_GETREGS, PTRACE_GETFPREGS, PTRACE_GETREGSET) y escribir en los registros (PTRACE_SETREGS, PTRACE_SETFPREGS, PTRACE_SETREGSET).
• Detener la ejecución (PTRACE_INTERRUPT) y forzar la ejecución de instrucciones una por una (PTRACE_SINGLESTEP).

The post Empezando a depurar codigo (I) appeared first on S3lab.