Conciencia del SO
La conciencia del SO de Simics es un módulo de Simics que entiende las estructuras de datos y las abstracciones del sistema operativo que se ejecuta en el sistema objetivo de Simics. Con el conocimiento del SO, Simics y el depurador de Simics conocen el espacio del kernel, el espacio del usuario, los procesos, los hilos y las tareas.
Fundamentalmente, el conocimiento del SO realiza dos tareas: el seguimiento en vivo de los eventos a medida que se producen y la investigación del estado instantáneo del sistema operativo. El seguimiento en vivo de los eventos significa que la conciencia del SO detecta cuando el sistema operativo realiza un cambio de tarea, cuando el software hace una llamada al sistema o cuando se producen interrupciones. De hecho, la forma más habitual de detectar estos eventos es esperar a que se produzcan interrupciones en el sistema de destino: mientras no se produzcan interrupciones, se estará ejecutando el mismo software a nivel de usuario. Cuando se produce una interrupción, el sistema operativo toma el control y se considera que el proceso en ejecución se ha desconectado. Cuando el sistema operativo vuelve al espacio de usuario, se considera que algún proceso ha sido conmutado.
El seguimiento en vivo determina cuándo ocurre algo, pero determinar qué ha ocurrido requiere investigar el estado instantáneo del sistema operativo. Por ejemplo, cuando se dispara una interrupción, ¿cuáles son los hilos activos en el procesador que recibió la interrupción? Para determinarlo, la conciencia del sistema operativo necesita conocer la estructura de las colas del sistema operativo de los procesos en ejecución y en espera, el contenido de los structs de tareas o bloques de control de procesos, y otras estructuras de datos. Siempre que esto se haya configurado correctamente, la conciencia del SO puede recorrer las listas en la memoria de destino y determinar el nombre del proceso actualmente activo en un procesador en particular, todos los procesos existentes, los módulos de software cargados dinámicamente y sus direcciones de reubicación, y cualquier otra cosa de interés.
Debido a que el contenido preciso de los structs de tareas y los offsets de campos particulares pueden variar entre las construcciones y versiones del sistema operativo, la conciencia del SO tiene que ser configurada antes de que pueda ser utilizada. La mayoría de las veces, es posible determinar los parámetros para el conocimiento del SO mirando una tabla de símbolos o un archivo del kernel con información de depuración de la compilación del SO. Sin embargo, hay sistemas operativos en los que los parámetros precisos no pueden determinarse hasta el tiempo de ejecución, y en estos casos la configuración tendrá que esperar hasta que el sistema de destino haya arrancado. En cualquier caso, una vez determinado, el conjunto de parámetros puede guardarse y utilizarse la próxima vez que se ejecute la misma configuración de destino.
El uso de archivos de parámetros hace posible que las configuraciones de conocimiento del SO se distribuyan junto con las imágenes del SO a las que se refieren. Esto significa que un equipo de plataforma puede construir una imagen del SO, configurar el conocimiento del SO para ella, guardar los parámetros y suministrar a sus usuarios el SO y sus parámetros de conocimiento del SO sin tener que proporcionar archivos de símbolos o información de depuración. El archivo de parámetros de conocimiento del SO es simplemente parte de la pila de software proporcionada, y se activa en los scripts de inicio utilizados para arrancar Simics. Los usuarios del sistema no necesitan saber cómo configurar el conocimiento del sistema operativo, simplemente lo ponen en funcionamiento en cuanto inician las configuraciones del sistema de destino proporcionadas. Los parámetros de conocimiento del SO también se guardan dentro de los archivos de puntos de control de Simics, de modo que el conocimiento del SO sigue funcionando a través de las operaciones de guardado y restauración de puntos de control.
El conocimiento del SO hace posible que las características de Simics funcionen sólo en un subconjunto particular de la pila de software, como tener puntos de interrupción establecidos sólo dentro de un determinado proceso, o rastrear sólo los accesos a la memoria realizados por el kernel y no por las tareas de nivel de usuario. Una extensión de Simics escrita por el usuario o un script pueden escuchar los eventos del conocimiento del SO y tomar acciones basadas en qué software se está ejecutando actualmente en el sistema objetivo. Es posible solicitar al sistema de conocimiento del SO notificaciones sólo para un determinado proceso, o ver todas las acciones de todos los procesos.
El sistema de conocimiento del SO en Simics opera con el concepto de un árbol de nodos. Cada nodo del árbol representa un nivel de abstracción en el modelo de procesos del SO. Típicamente, el nodo superior es el propio sistema operativo, que luego se divide en tareas de nivel de núcleo y de usuario. En un sistema operativo como Linux, cada tarea a nivel de usuario contiene uno o más hilos. En el núcleo, el conocimiento del sistema operativo normalmente distingue los hilos del núcleo de la tarea inactiva, porque eso ayuda a explicar el tiempo de ejecución del objetivo. La figura 3.3 muestra un ejemplo de árbol de nodos de un sistema Linux barebones.
Figura 3.3. Árbol de conocimiento del SO.
En la CLI y la GUI del depurador de Simics, las consultas de procesos se utilizan para encontrar procesos de interés. Estas consultas pueden coincidir con los nombres de los procesos, los números de identificación de los procesos, u otras propiedades puestas a disposición por el conocimiento del SO. En la mayoría de los casos, el nombre de un proceso es suficiente para identificarlo, pero en sistemas complejos se necesitan coincidencias más complejas como «el proceso llamado foo en la placa llamada bar». En un sistema de larga duración en el que un determinado programa se ejecuta muchas veces, el ID del proceso se puede utilizar para identificar un inicio particular de un proceso.
Simics OS awareness soporta sistemas operativos anidados para manejar OS awareness para sistemas basados en hipervisor. En un sistema con un hipervisor, es necesario rastrear la programación de los sistemas operativos invitados en los núcleos del procesador de destino. Una vez que se ha determinado el sistema operativo activo en un núcleo, es posible aplicar la conciencia del SO para ese sistema operativo para determinar el proceso o hilo activo. De este modo, se utiliza un único árbol para todo el sistema, enraizado en el hipervisor.
Los detalles de lo que el conocimiento del SO puede rastrear y descubrir acerca de la pila de software de destino varía en función del sistema operativo invitado y de cuánto trabajo se ha invertido en la construcción del conocimiento del SO para él.
Comparado con los sistemas de conocimiento del SO utilizados con depuradores basados en hardware (JTAG), la capacidad de un simulador para rastrear con precisión los cambios de tareas es única. Tales características han demostrado ser poco prácticas para implementar en depuradores basados en hardware, ya que incurrirían en una sobrecarga significativa y abrumarían la disponibilidad de puntos de interrupción de hardware. La inspección del estado instantáneo es esencialmente la misma que la inspección de un depurador de hardware del estado del sistema después de detener el sistema, y de hecho el mismo código que se utiliza para los depuradores de hardware se ha utilizado con Simics para determinar hechos como las direcciones de reubicación para los módulos cargados dinámicamente.
Un depurador basado en agentes no necesita conocimiento del sistema operativo, porque se está ejecutando dentro del sistema de destino y puede utilizar las API del sistema operativo para preguntar al sistema operativo de destino sobre las tareas en ejecución, los módulos cargados, y otra información.