Paso a paso (depuración)

Este artículo incluye una lista de referencias , lecturas relacionadas o enlaces externos , pero sus fuentes no están claras porque carece de citas en línea . Ayúdenos a mejorar este artículo introduciendo citas más precisas. ( Mayo de 2022 ) ( Aprenda cómo y cuándo eliminar este mensaje )

La animación o ejecución de programas se refiere al método de depuración que consiste en ejecutar código una instrucción o línea a la vez. El programador puede examinar el estado del programa, la máquina y los datos relacionados antes y después de la ejecución de una determinada línea de código. Esto permite al programador evaluar los efectos de cada instrucción o declaración de forma aislada y, de ese modo, obtener información sobre el comportamiento (o el mal comportamiento) del programa en ejecución. Casi todos los IDE y depuradores modernos admiten este modo de ejecución.

El paso de instrucciones o ciclo único se refería originalmente a la técnica de detener el reloj del procesador y avanzarlo manualmente un ciclo a la vez. Para que esto sea posible, se requieren tres cosas:

• Un control que permite detener el reloj (por ejemplo, un botón "Detener").
• Un segundo control que permite avanzar manualmente un ciclo el reloj parado (por ejemplo, un interruptor de "paso de instrucción" y un botón de "Inicio").
• Algunos medios para registrar el estado del procesador después de cada ciclo (por ejemplo, pantallas de registros y memoria).

En la gama de procesadores IBM System 360 anunciada en 1964, estas funciones se proporcionaban mediante interruptores, botones y grupos de luces de neón en el panel frontal. Otros sistemas, como el PDP-11 , ofrecían funciones similares.

En los procesadores más nuevos, que pueden no soportar la detención física del reloj y tienen demasiado estado interno para mostrarlo razonablemente en un panel, se puede proporcionar una funcionalidad similar a través de un indicador de trampa , que cuando se habilita, le indica al procesador que se detenga después de cada instrucción de manera similar a un punto de interrupción .

A medida que el multiprocesamiento se hizo más común, estas técnicas tuvieron una utilidad práctica limitada, ya que muchos procesos independientes se detenían simultáneamente. Esto llevó al desarrollo de software propietario de varios proveedores independientes que proporcionaban características similares pero restringían deliberadamente los puntos de interrupción y la ejecución de instrucciones a programas de aplicación particulares en espacios de direcciones y subprocesos particulares . El estado del programa (según fuera aplicable a la aplicación/subproceso elegido) se guardaba para examinarlo en cada paso y se restauraba antes de la reanudación, lo que daba la impresión de un entorno de usuario único. Esto normalmente es suficiente para diagnosticar problemas en la capa de aplicación.

En lugar de utilizar un botón de detención físico para suspender la ejecución, para luego comenzar a avanzar por el programa de aplicación, generalmente se debe establecer de antemano un punto de interrupción o una solicitud de "Pausa", generalmente en una instrucción o declaración particular en el programa (elegida de antemano o, alternativamente, de manera predeterminada, en la primera instrucción).

Para proporcionar una "animación" de pantalla completa de un programa, normalmente se requiere un dispositivo de E/S adecuado, como un monitor de vídeo, que pueda mostrar una sección razonable del código (por ejemplo, en formato de código fuente o código de máquina desensamblado ) y proporcionar un puntero (por ejemplo, <==) a la instrucción o línea actual del código fuente. Por este motivo, el uso generalizado de estos animadores de pantalla completa en el mundo de los mainframes tuvo que esperar a la llegada de los sistemas de procesamiento de transacciones , como CICS a principios de los años 70, y se limitaron inicialmente a la depuración de programas de aplicación que operaban en ese entorno. Las versiones posteriores de los mismos productos proporcionaron supervisión y depuración entre regiones de programas por lotes y otros sistemas operativos y plataformas.

Con la introducción mucho más tardía de las computadoras personales a partir de 1980, los depuradores integrados pudieron incorporarse más ampliamente en este dominio de usuario único y proporcionaron una animación similar al dividir la pantalla del usuario y agregar una "consola" de depuración para proporcionar interacción con el programador.

Borland Turbo Debugger fue un producto independiente presentado en 1989 que ofrecía animación de programas en pantalla completa para PC. Las versiones posteriores añadieron compatibilidad para combinar la animación con líneas de código fuente reales extraídas en el momento de la compilación.

Existen al menos tres técnicas de software distintas para crear "animación" durante la ejecución de un programa.

• La instrumentación implica agregar código fuente adicional al programa en tiempo de compilación para llamar al animador antes o después de cada instrucción para detener la ejecución normal. Esta funcionalidad puede ser parte de la biblioteca de tiempo de ejecución , como en el módulo pdb de Python, o puede tomar la forma de insertar una instrucción de punto de interrupción que active un depurador externo si hay uno conectado.
• Interrupción inducida Esta técnica implica forzar un punto de interrupción en ciertos puntos de un programa en el momento de la ejecución, generalmente alterando la instrucción del código de máquina en ese punto (puede ser una llamada al sistema insertada o una operación inválida deliberada) y esperando una interrupción. Cuando se produce la interrupción, la herramienta de prueba la gestiona para informar el estado al programador. Este método permite la ejecución del programa a toda velocidad (hasta que se produce la interrupción), pero tiene la desventaja de que la mayoría de las instrucciones que conducen a la interrupción no son supervisadas por la herramienta.
• Simulador de conjunto de instrucciones Esta técnica trata el código de máquina del programa compiladocomo sus 'datos' de entrada y simula completamente las instrucciones de la máquina host, monitorea el código en busca de puntos de interrupción condicionales o incondicionales o solicitudes de animación de "ciclo único" solicitadas por el programador entre cada paso.

La ventaja del último método es que no se realizan cambios en el programa compilado para proporcionar el diagnóstico y hay un alcance casi ilimitado para diagnósticos extensos ya que la herramienta puede aumentar los diagnósticos del sistema host con características de seguimiento de software adicionales. También es posible diagnosticar (y prevenir) muchos errores de programa automáticamente usando esta técnica, incluidas violaciones de almacenamiento y desbordamientos de búfer . La detección de bucles también es posible usando el seguimiento automático de instrucciones junto con umbrales de conteo de instrucciones (por ejemplo, pausa después de 10,000 instrucciones; mostrar las últimas n instrucciones) El segundo método solo altera la instrucción que se detendrá antes de que se ejecute y también puede restaurarla antes de la reanudación opcional por parte del programador. Algunos animadores permiten opcionalmente el uso de más de un método según los requisitos. Por ejemplo, usar el método 2 para ejecutar hasta un punto particular a toda velocidad y luego usar la simulación del conjunto de instrucciones a partir de entonces.

El animador puede, o no, combinar otras funciones de prueba/depuración dentro de él, como seguimiento de programa , volcado, punto de interrupción condicional y alteración de memoria , alteración del flujo del programa , análisis de cobertura de código , detección de "puntos calientes", detección de bucles o similares.

• Descripción general de la compatibilidad con pasos en el IDE de Microsoft Corporation , Visual Studio
• Tarraingim - Un entorno de animación de programas
• Animación de programas como forma de enseñar y aprender sobre diseño y análisis de programas
• Información estructurada sobre pruebas de software (como la Historia de las pruebas de software) publicada por referencias de pruebas