Análisis de la ubicación de los segmentos de código de un programa bajo RISC OS

Abstract

RESUMEN: Las asignaturas Introducción a los Computadores y Estructura de Computadores, impartidas por la Universidad de Cantabria a los alumnos de ingeniería informática, se centran en explicar aspectos fundamentales del funcionamiento de un computador. Como parte de la formación práctica de las asignaturas, se solicita al alumnado que implemente diferentes programas en lenguaje ensamblador para la arquitectura ARM. Una de las herramientas más utilizadas durante estas prácticas es el depurador. Esta herramienta permite a los alumnos ejecutar el código desarrollado controlando el número de instrucciones que se ejecutan, y mostrando qué tipo de fallos presenta el programa que se está depurando. Sin embargo, el sistema operativo bajo el que se realizan las prácticas, RISC OS, no poseía un depurador de código abierto que se pudiese utilizar durante las prácticas. Por ello, desde el departamento de Ingeniería Informática y Electrónica de la UC se ha desarrollado un depurador propio denominado UCDebug, en el marco de un proyecto de innovación docente. Durante su desarrollo se primó la simplicidad del código y la pronta disponibilidad para su adopción en las asignaturas involucradas. El depurador UCDebug ejecuta los programas del alumno como si fuesen parte de su propio código. Como restricción inherente a esta estrategia de diseño, para que un programa pueda ser depurado en la herramienta, se debe enlazar el código de este a una dirección diferente a la habitual en el sistema operativo. Esto provoca que el alumno deba enlazar el código en dos direcciones diferentes, una para ejecutarlo directamente sobre RISC OS y otra para poder depurarlo con la herramienta. Durante este proyecto se realiza un estudio de la viabilidad de una propuesta de mejora para el depurador, mediante la cual ya no sería necesario enlazar el código que se quiera depurar a una dirección diferente a la usada por el sistema operativo. La modificación propuesta consiste en reubicar los segmentos de código que componen el ejecutable del depurador. Con este cambio, sería posible cargar en este espacio el código que se quiere depurar. Como resultado de esta modificación obtendríamos que el código que se depura en la herramienta se ubica en las mismas direcciones de memoria a las que se encontraría si se ejecutase directamente bajo RISC OS, no siendo necesario enlazar el programa del alumno a direcciones diferentes. Este proceso no es trivial, ya que el depurador es también una aplicación que se ejecuta bajo RISC OS. Por ello, necesita ubicarse al comienzo del espacio de direcciones de memoria de usuario, donde se pretende colocar el programa del alumno. Además, durante el desarrollo de la herramienta se han utilizado de forma conjunta los lenguajes C y ensamblador, haciendo uso de varias librerías propias del sistema operativo RISC OS. Previsiblemente, el uso de estas librerías puede complicar el proceso de análisis, debido a que no hay información previa acerca de cómo estas librerías son tratadas por el compilador y el linker. El trabajo consiste en un análisis de los diferentes segmentos de código que componen un fichero ejecutable, y, en concreto, los que componen el depurador, ideando consecuentemente diferentes estrategias de reubicación. Este análisis ha demostrado que es posible reubicar los segmentos del código que componen el ejecutable, pero que no es posible situarlos al comienzo del espacio de direcciones. Esto es debido a que los ficheros ejecutables comienzan con una cabecera con información sobre la estructura del programa y que no puede reubicarse. Durante el desarrollo del proyecto se ha determinado que no es posible sobrescribir esta cabecera de forma completa. No obstante, el programa del alumno que se quiere depurar tiene una cabecera del mismo tamaño. Además, durante la depuración, el código del alumno se trata como parte del propio código del depurador, por lo que se ha determinado que no necesita de sus cabeceras originales para ser ejecutado. Por lo tanto, si se obvian durante el cargado del código las cabeceras, el programa seguiría situado en la misma dirección en memoria, no siendo necesario un enlazado adicional. Se ha determinado, por tanto, que la propuesta de mejora es viable, y que para ser realizada se debe alojar un segmento con espacio reservado al comienzo del espacio de direcciones de memoria del depurador. 3 Además, se deben obviar las cabeceras durante el copiado del código del alumno al depurador, tal y como se muestra más detalladamente en este documento.

ABSTRACT: The courses Introduction to Computers and Computer Structures given at the University of Cantabria to computer engineering students focus on explaining fundamental aspects of how a computer works. Among the topics covered are programming in assembler language under the ARM architecture. Consequently, in the practical part of the courses, students are asked to implement different programs in that language. One of the most used tools during these sessions is the debugger. This tool allows students to execute their codes in a controlled fashion, showing what kind of failures the program being debugged presents. However, the operating system under which the practices are carried out, RISC OS, did not have an open source debugger with a graphical user interface.Therefore, a new tool called UCDebug has been developed within the Department of Computer and Electronic Engineering, as part of a teaching innovation project. During its development, the simplicity of the code and the prompt availability for its adoption in the courses involved were paramount. UCDebug runs the student programs as if they were part of its code. As an inherent restriction of this design strategy, in order for a program to be debugged in the tool, its code must be linked to a different address than the usual one in the operating system. This causes the student to link the code in two different directions, one to run it directly on RISC OS and the other to run it on the tool during the debugging process. During the project, a study of the feasibility of an improvement proposal for the debugger is carried out, by means of which it would no longer be necessary to link the code to be debugged to an address different from the one used by the operating system. The proposed modification consists of relocating the code segments that make up the debugger executable so that the initial segment remains available in memory. With this change, it would be possible to load in this space the code that you want to debug. As a result of this modification, the code debugged in the tool would be located in the same memory addresses as if it were executed directly under RISC OS, removing the need to link the student program to different addresses. This process is not trivial, since the debugger is also an application running under RISC OS, so it needs to be located at the beginning of the user memory address space, where the student program is intended to be placed. In addition, during the development of the tool have been used together the C and assembler languages, making use of several libraries of the RISC OS operating system. Therefore, an analysis of the different code segments that make up an executable file, and specifically tho se that make up the debugger, has been carried out, consequently devising different relocation strategies. This analysis has shown that it is possible to relocate the code segments that make up the executable, but that it is not possible to place them at the beginning of the address space. This is due to the presence of a header at the beginning of the executable file, indicating the memory structure of the program. During the development of the project it has been determined that it is not possible to overwrite this header. However, the student program has a header with the same size and memory location. Additio nally, during debugging, the student code is treated as part of the debugger code itself, so it has been determined that its headers are not needed for its execution. If the headers are skipped during code loa ding, the program will continue to be located at the same address in memory, not requiring an additional linking process. Therefore, it has been determined that the improvement proposal is feasible, and that to be carried out, a segment with reserved space must be accommodated at the beginning of the debugger address space. Headers must also be skipped when copying the code from the student to the debugger.