visualizador didÁctico de ejecuciÓn para lc99

VISUALIZADOR DIDÁCTICO

DE EJECUCIÓN PARA LC99

Tutores: Miguel Ángel Pérez AguiarJosé Fortes Gálvez

Facultad de InformáticaUniversidad de Las Palmas de

G.C.

Autor: Daniel Bautista de Cabo

24/04/23 Visualizador Didáctico de Ejecución 2

El proceso de la ejecución

http://www.itmweb.com/methodology/wmethod.htm


El Visualizador de Ejecución


Contenidos Introducción Estado inicial del tema Metodología seguida Recursos utilizados Planificación y desarrollo del proyecto Resultados y conclusiones Trabajo futuro


¿Qué es LC99? Lenguaje inspirado en Algol y Pascal Desarrollado en la E.U.I. de la ULPGC Características interesantes para la

gestión de memoria (didáctico) Existe un compilador y actualmente

no acepta todo el lenguaje El compilador genera “código P”

ESTADO INICIAL


Estado inicial (I) Proyecto muy relacionado con un

depurador (gráfico): Depuradores capaces de controlar flujo de

un programa Depuradores pueden consultar estado de

un programa (variables, argumentos, registros, memoria)

Pero, ¿es un depurador lo suficientemente didáctico para estudiar el modelo de gestión de la memoria?

Estudio de los depuradores actuales


GDB (GNU DeBugger) El GDB es un depurador conocido Puede depurar programas en C, C++,

Pascal, Fortran, Modula2, Ada y otros Modo texto (consola) “crudo”, no

didáctico Sin embargo, cubre todas nuestras

necesidades de contenidos


DDD Depurador gráfico más conocido en

Linux Sólo una GUI, su motor es el GDB Permite interacción directa con el GDB Potencia GDB + Amigabilidad visual Sin embargo, sigue siendo “crudo” con

la visualización de la memoria (simplemente encierra el texto del GDB en ventanas)


Estado inicial (II): Conclusión

Mismo problema en todos los depuradores estudiados: visualización pobre de la memoria

Esto es lógico, dado el fin de un depurador: un programador no suele estar interesado en el modelo de gestión de la memoria

No encontraremos un depurador que funcione como visualizador didáctico

Detalle interesante: potencia y capacidad del GDB de aceptar varios lenguajes

METODOLOGÍA


Metodología (I) Se ha seguido un ciclo de vida en

cascada Se ha utilizado UML para diseñar y

documentar Documentación durante el desarrollo Otras metodologías (PUD, …) eran

excesivas para este proyecto


Metodología (II)

RECURSOS UTILIZADOS


Recursos utilizados Se ha tratado de usar software

libre cuando ha sido posible: Borland Kylix 3 Open Edition, IDE

Builder(en Windows: Borland C++ Builder)

Herramientas GNU: GDB, GCC, GPC, GNAT, G++, G77

GNU para Windows: MinGW, Cygwin

PLANIFICACIÓN Y TIEMPOS


Planificación

Análisis: 80

Diseño: 30

Implementación: 90

Pruebas: 60

Documentación: 40

(300 horas)


Tiempos y porcentajes

Análisis: 50

Diseño: 52

Implementación: 130

Pruebas: 18

Documentación: 50

(300 horas)

ANÁLISIS


Análisis (I) Qué queríamos:

Herramienta con potencia de depurador: control del programa, recuperación de valores, etc.

Herramienta que visualice la memoria de forma didáctica

Herramienta que acepte el LC99 (completo) Herramienta extensible (que pueda aceptar

otros lenguajes)


Análisis (II) Identificación de elementos de

visualización: Código fuente Código máquina (ensamblador) Pila Registros Resto de la memoria

Inspiración: depuradores + apuntes de gestión de memoria


Análisis (III) Estudio de los depuradores Dos hechos interesantes:

Potencia del GDB al aceptar varios lenguajes

Que DDD (y otros) utilizaran al GDB


Análisis (IV) Idea: Diseñar e implementar un

visualizador que use GDB (como el DDD)

Problema: GDB no acepta código generado por compilador de LC99 (genera “código P”)

Solución: cambiar código generado por compilador de LC99 (backend)


Estudio del GDB ¿Cómo obtiene el GDB información

semántica sobre un programa? Entrada GDB: ejecutable Hay que compilar con la opción “-

g” ¿Qué ocurre cuando se especifica

esa opción?


Los STABs Con opción “-g”, el compilador añade más

líneas al código generado (ensamblador) Cada una de esas líneas se llama STAB STAB=Symbol TABle: codifican

información semántica Los STABs especifican los nombres de las

variables, argumentos, funciones; línea fuente en que han sido declarados; de qué tipo son; y su lugar en memoria

.stabs “c(0,1)”,128,0,2,-4

Indica que hay una variable “c” entera enla posición -4 a partir del registro %ebp


Nuevo compilador de LC99

Habrá que cambiar el código generado: De “código P” a código ensamblador AT&T i386

(parecido a Intel pero con pequeñas diferencias) Añadir líneas de STAB al código i386 generado

DISEÑO


Diseño (I)


Diseño (II) “Intermediario” entre el GDB y el

visualizador (VDE) Principio de diseño: encapsular lo

que cambia El intermediario envía órdenes y

recoge respuestas del GDB y se las pasa al VDE


Diseño (III)


Diseño (IV) Realimentación entre diseño e

implementación: nuevas ideas que han hecho necesario rediseñar

Patrones de diseño: Mediator, Singleton

IMPLEMENTACIÓN


Implementación (I) Lenguaje utilizado: C++

Experiencia Se usa la librería LibC

GUI (Kylix/Builder) Propuesta inicial: Delphi Productividad Experiencia


Implementación (II): fork

VDE

VDE VDE (hijo)

GDB

fork

exec

pipe

dup

En Windows: Win32 API• CreateProcess()• Anonymous Pipes


Implementación (III): GDB

Intermediario analiza y estructura repuestas de salida estándar del GDB

Respuestas del GDB fijas Posibilidad de usar GDB MI

(Machine Interface), pero sólo disponible a partir de GDB 5.0


Implementación (IV): hilos

GUI

Intermediario

GDB

Usuario

acción

petición

comando

respuesta

respuesta

respuesta (visual)

Proceso de comunicación:

VDE


Implementación (V): hilos

GUI

Intermediario

GDB

Usuario

acción

petición

comando

respuesta

respuesta

respuesta (visual) VDE

VDE::Hilo

Para evitar bloqueos se utiliza concurrencia (hilos):


Implementación (VI): bugs

VDE soluciona bugs del GDB Información incorrecta si paramos el

GDB en entrada o salida de función VDE detecta esos casos y, con la

información del instante anterior, construye visualización correcta

Si no hubo paso anterior, simplemente no etiqueta valores críticos


Implementación (VII) Sentido de la pila:

¿Hacia dónde crece la pila?

Literatura muestra ambos sentidos

Ningún argumento concluyente: se deja elegir al usuario


Implementación (VIII) No se puede ir hacia atrás en el

flujo de ejecución Sin lo anterior, es difícil comparar

la pila en dos estados diferentes Solución: poder capturar estado

de pila (snapshot), para comparar más tarde


Scripts adaptadores (I) Para algunos lenguajes, el visualizador

no se comporta adecuadamente Sería más correcto decir que el GDB no

se comporta correctamente Enlace estático no se etiqueta como

STAB (el LC99 sí lo hace; GPC y GNAT, obviamente, no)

Esto provoca que el enlace estático no se etiquete (aunque sí aparece su valor, adónde apunta, etc.)


Scripts adaptadores (II) Implementación de scripts en Perl

que modifican código generado (GPC y GNAT)

GPC no funciona con GDB, script logra que funcione


Scripts adaptadores (III)

C (gcc)C++ (g++)Fortran (g77)

Ada (gnat)Pascal (gpc)

LC99 (lc99)

scriptscript

PRUEBAS


Pruebas (I) Se plantearon varias pruebas:

Batería de programas Pruebas de usuario Pruebas de sistema o entorno Pruebas de memoria


Pruebas (II) Batería de programas:

Procedimientos anidados (Pascal, Ada, LC99) Recursividad Estructuras complejas (arrays, structs) Clases y objetos (C++) Hilos, tareas (Ada) Punteros (C) Distintos pasos de parámetros (valor,

referencia) Varios fuentes (uses, include) Optimización (gcc) No optimizar


Pruebas (III) Pruebas de usuario: se repartió el

VDE a diferentes usuarios Pruebas de sistema: Windows ME,

2k, XP; Linux (entornos KDE, GNOME, …)

Pruebas de memoria (C++): se usó MemProof para validar que no se pierde memoria

RESULTADOS


Resultados VDE capaz de visualizar programas

LC99 VDE capaz (por usar GDB) de

visualizar programas C, C++, Pascal, Ada95 y Fortran77 (probados), y otros

Visualización etiquetada y estructurada

Potencia de un depurador gráfico Disponible en Linux y Windows


Página web Durante el desarrollo del proyecto

se mantuvo una página web para la comunicación alumno-tutores

Esa página web se ha ido transformando en la página del proyecto

Incluye fuentes, ejecutables, capturas, documentación y enlaces


Conocimientos aplicados

Procesadores de Lenguajes Ingeniería del Software Programación Orientada a Objetos, GUI Programación en C, Pascal, Perl, etc. Concurrencia Sistemas Operativos Gráficos por Computador

TRABAJO FUTURO


Ampliaciones Construcción de nuevos

compiladores compatibles con el VDE Adaptación de compiladores antiguos GDB/MI Uso de otros depuradores (jdb, …) Gestión interna del heap


Referencias (I) [PER 98] “Traductores e Intérpretes”. E.U.I.-U.L.P.G.C., Miguel Ángel

Pérez Aguiar, 1998. [SAN 99] Proyecto de fin de carrera de la E.U.I.-U.L.P.G.C. "Prototipo

de Compilador Didáctico del Lenguaje LC99", Tomos I y II, Orlando Sánchez Montesdeoca, 1999.

[PEM 82] "P4. Pascal Implementation: Compiler and Assembler/Interpreter", Steven Pemberton and Martin Daniels, 1982.

[ROS 96] "How Debuggers Work", Jonathan Rosenberg, 1996. [UML 99] “El Lenguaje Unificado de Modelado”, Grady Booch, James

Rumbaugh, Ivar Jacobson, Ed. Addison-Wesley, 1999 [GAM 95] "Patrones de Diseño", Erich Gamma, Richard Helm, Ralph

Johnson, John Vlissides, 1995. [TRU 97] Apuntes de Fundamentos Gráficos por Computador. E.U.I.-

U.L.P.G.C., Agustín Trujillo Pino, 1997. [ROD 00] Técnicas y Metodología Orientada a Objetos. C++. Juan

Carlos Rodríguez del Pino, Margarita Díaz Roca, José Daniel González Domínguez, 2000.


Referencias (II) Página oficial del depurador GDB: http://www.gnu.org/software/gdb/gdb.html Más información sobre el GDB:

http://developer.apple.com/techpubs/macosx/DeveloperTools/ Formato STABS del GDB: http://sources.redhat.com/gdb/onlinedocs/stabs.html Página web del proyecto LC99:

http://serdis.dis.ulpgc.es/~itis-ti2/PrototipodeCompiladorDidacticoLC99/ Visualización de la máquina P: http://rw4.cs.uni-sb.de/~martin/COMP/info.html Página de la interfaz gráfica DDD: http://www.gnu.org/software/ddd/ Página oficial del GCC: http://gnuwww.epfl.ch/software/gcc/gcc.html Cómo añadir un front-end al GCC:

http://ldp.kernelnotes.de/HOWTO/GCC-Frontend-HOWTO.html#toc5 Página oficial del GPC: http://www.gnu-pascal.de Página oficial del GNAT: http://www.gnat.com Página oficial de MINGW: http://www.mingw.org Página oficial de CYGWIN: http://www.cygwin.com Información sobre el 80386: http://www.alpertron.com.ar/80386.HTM Comunicación entre procesos en Win32:

http://bdn.borland.com/article/0,1410,10387,00.html

visualizador didÁctico de ejecuciÓn para lc99

Documents