Capítulo 5. Conclusiones

Tabla de contenidos
5.1. Conclusión y valoración
5.2. Trabajo futuro

Por último, en este apartado se hace una valoración personal del proyecto, tanto a nivel de conclusiones como conocimiento adquiridos con él. Finalmente se añade otra sección donde explico algunos objetivos futuros que podrían incrementar la potencia y funcionalidad de este "software".

5.1. Conclusión y valoración

Tanto la instrumentación de código, como la manipulación de ejecutables y los ABI son asuntos muy poco tratados en general pero que, desde mi punto de vista, me han parecido muy interesantes. Este proyecto me ha permitido trabajar, investigar y aprender muchisimo sobre diferentes arquitecturas, sobre como funciona realmente el proceso de carga y el enlace en tiempo de ejecución y me ha introducido en el mundo de la instrumentación de código.

Ha sido todo un desafio, tanto de aprendizaje como de programación, en el que he podido aprender cosas que muy dificilmente hubiese podido aprender en la empresa privada o por cuenta propia.

Desde siempre he sentido un interés por el ensamblador, el "hardware" a bajo nivel y por saber como funciona realmente un sistema operativo. Cuando cogí este proyecto, al igual que mucha gente, tenía una visión muy simplificada y lejana de la realidad de los ABI. Generalmente se explican los formatos de enlace dinámico con cuatro diagramas y sin profundizar sobre como funciona en realidad. Cuando se mira detenidamente se descubre que lo que parece simple no es nada simple. El formato de los binarios es una de las bases de un sistema operativo, y decide en gran parte el rendimiento de un sistema[1]. El formato ELF es un formato de enlace donde esta cuidado hasta el último detalle, nunca falta o sobra información. Es lo suficiente compacto como para funcionar en maquinas empotradas y lo suficiente potente como para ser la base de grandes servidores.

Debido a que sólo se ha trabajado con estructuras ELF, sin usar información de depuración ni funcionalidades extraordinarias del sistema operativo, el resultado final no sólo es altamente portable y apenas tiene impacto en el rendimiento de la aplicación instrumentada, sino que además pDI-Tools funciona con cualquier tipo de ejecutable. Esto es muy bueno ya que abre un abanico de posibilidades amplísimo a pDI-Tools para que en el futuro sea usado no sólo en entornos con máquinas paralelas. Por ejemplo podría ser usado también para realizar ejecuciones conducidas y así testear "software".

Otro gran punto enriquecedor de este proyecto ha sido la gran cantidad de arquitecturas y sistemas operativos sobre los que he trabajado: desde la plataforma más común INTEL® 386 hasta carísimos PowerPC™ 64 o MIPS®. En total se ha portado pDI-Tools sobre siete ABI's y tres sistemas operativos distintos, y se trabajó durante un corto periodo de tiempo sobre Itanium®[2]. Esto me ha permitido tener una visión muy clara y a la vez cuidadosa sobre como se implementa ELF (y algunos aspectos de COFF) en los sistemas Unix™ actuales.

Además, haber portado pDI-Tools de nuevo a la plataforma original de DITools (Irix para MIPS®) permite que se porte OMPItrace, una aplicación de instrumentación desarrollada por el CEPBA, a pDI-Tools. De esta forma en el futuro se podrá portar casi automáticamente OMPItrace a otras arquitecturas.

Como hemos ya comentado, hay muy poca información sobre estos temas, y se ha tenido que realizar una gran labor de investigación. De hecho, a parte de las especificaciones, no se han encontrado apenas artículos o documentos "serios" sobre ELF y se ha recurrido en muchas ocasiones a "ezines" de "hackers", listas de correos, notas en algunas páginas web, foros y sobretodo código fuente y en ocasiones a desensamblar partes del sistema operativo a mano. Esto sin duda ha sido una de las partes más duras, pero también más interesante, del proyecto. Me he visto obligado en muchas ocasiones a agudizar el ingenio y ha hecho que el resultado sea muchísimo más satisfactorio.

Además ha sido una aplicación difícil de escribir ya que en este tipo de software no se pueden tolerar errores. En un programa como este es crítico revisar su correcto funcionamiento, ya que un mínimo fallo puede significar mediciones incorrectas en la instrumentación y en el peor de los casos, si aborta, puede representar muchas horas de trabajo y recursos perdidos. Por ello ha sido un desarrollo duro ya que se ha repasado cuidadosamente cada función para garantizar un buen funcionamiento.

Por otro lado este proyecto me ha permitido refinar mis conocimientos en interfaces de usuario ofreciendo en pDI-Tools una facilidad de uso superior al antiguo DITools. Se ha simplificado mucho la detección de errores o interacciones entre interposiciones, además de que se ha ocultado al máximo al usuario las limitaciones y características del "Runtime Linker" ofreciendole una interfaz sencilla y clara con la cual poder crear herramientas de instrumentación altamente portables.

Otro objetivo que tenía con pDI-Tools era la creación de un proyecto de "software" libre de principio a fin, es decir, no sólo entregar el código bajo una licencia libre (LGPL), sino un proyecto con una documentación libre en un formato libre, su sistema de configuración e instalación portable, su propia página web del proyecto y que esté presente en un repositorio público de "software" libre. Este objetivo me ha obligado a aprender muchisimo no sólo sobre tecnología, sino sobre el movimiento GNU, su filosofía y sobre el "open source" en general.

Por último he aprovechado el hecho de escribir esta documentación para ponerme al día sobre XML, SGML y otras tecnologías del W3C®. Para escribir la documentación se ha usado DocBook/XSL, un lenguaje XML especial para escribir libros. Es usado por la editorial O'Reilly® para todas sus publicaciones y permite escribir documentos sin centrarse en su presentación, sino tan sólo en su contenido. Esto me ha obligado a aprender muchísimo y crear un entorno de trabajo basado en DocBook/XSL con sus "scripts" de renderización de documentos y proceso de documentos XML, hojas de transformación XSLT y hojas de estilo DSSSL.

En último lugar, pero no precisamente es lo menos importante, es que este proyecto se ha compaginado a diario con mi trabajo de 5 horas diarias en una empresa de programación de herramientas de tratamiento de lenguaje por computador. Esto ha provocado que sólo se le haya podido dedicar unas 4 o 5 horas diarias de trabajo al proyecto, que además no podían ser muy intensas debido a que ya venía de una jornada de trabajo en otro sitio. Aún así estoy orgulloso del resultado por la cantidad y calidad del trabajo realizado teniendo en cuenta el poco tiempo del que disponía.

Notas

[1]

Como anécdota, el sistema operativo Mac OS™ X implementa un ABI inadecuado en su sistema operativo, provocando que las llamadas a funciones de otros DSO desde el programa principal sean más lentas que si hubiese seguido la especificación ELF para PowerPC™. Esto puede llegar a tener, teoricamente, una ejecución hasta un 10% más lenta (ver [Mach-O-ABI]).

[2]

Pero al terminar la cesión por Bull de la máquina Itanium® que tenía el CEPBA se tuvo que dejar de lado esta arquitectura.