Estoy escribiendo un marco para habilitar la cosimulación de RTL que se ejecuta en un simulador y un software host sin modificar. El software host está escrito para controlar el hardware real y, por lo general, funciona de dos maneras:
El primer caso es bastante sencillo: escriba una biblioteca que implemente las mismas llamadas de lectura/escritura que el controlador y enlace contra eso cuando se ejecuta una simulación. Todo esto funciona maravillosamente y puedo ejecutar software de producción sin modificar como estímulo para mis simulaciones RTL.
El segundo caso está resultando mucho más difícil que el primero...
Inicialmente pensé que podría usar LD_PRELOAD para interceptar la llamada mmap. En mi implementación de mmap , asignaría algo de memoria alineada con la página y luego la mprotect y configuraría un controlador de señal para atrapar SIGSEGV .
Existen numerosos problemas con este enfoque:
Leer vs Escribir
Puedo determinar la dirección del acceso desde siginfo_t->si_addr pero no si el acceso fue de lectura o escritura.
Captura de accesos repetidos
En el controlador de señales, necesito desproteger la región de la memoria; de lo contrario, obtendré SIGSEGV repetidos tan pronto como mi controlador salga y el código del host nunca podrá continuar. Sin embargo, si desprotejo la región, mi controlador de señal no atrapará los accesos posteriores.
Maldad del controlador de señal
Bloquear un controlador de señales mientras el simulador maneja el RTL y devuelve un resultado viola todo tipo de reglas de programación, particularmente dado que el simulador podría desencadenar todo tipo de otros eventos y ejecutar código arbitrario antes de devolver un resultado de este acceso.
Me preguntaba si es posible crear un objeto similar a un archivo que se comporte como un disco en lugar de usar mprotect en un búfer. No he encontrado ninguna información que sugiera que esto es factible.
¿Es posible atrapar todos los accesos a una región mmap y cómo?
Asumiendo LD_PRELOAD y mprotect es la mejor ruta:
mprotect la región?¿Cómo escribir un controlador de señal para capturar SIGSEGV?
Es posible atrapar la escritura en la dirección (x86 - linux)
En X86, puede configurar el indicador Trap para que el contexto de la persona que llama obtenga SIGTRAP después de una instrucción (este indicador se usa normalmente para un solo paso). Es decir, cuando se encuentra SIGSEGV, configura TF en EFLAGS de la persona que llama (consulte ucontext.h ), habilita la lectura con mprotect y regresa. Si SIGSEGV se repite instantáneamente con la misma IP, habilita la escritura (y opcionalmente deshabilita la lectura, si desea distinguir el acceso de lectura-modificación-escritura del acceso de solo escritura). Si obtiene SIGSEGV desde la misma IP para protección de solo lectura y solo escritura, habilite lectura y escritura.
Cada vez que obtiene SIGTRAP, puede analizar qué valor se escribió (si fue un acceso de escritura) y también puede volver a proteger la página para interceptar accesos futuros.
Corrección: si tanto las lecturas como las escrituras pueden tener efectos secundarios, intente primero la protección de solo escritura, luego aplique los efectos secundarios de lectura y pruebe la protección de solo lectura, luego habilite la escritura y maneje los efectos secundarios de la escritura en el controlador SIGTRAP final.
ACTUALIZACIÓN: Me equivoqué al recomendar una protección hipotética de solo escritura que resulta no existir en la mayoría de las arquitecturas. Afortunadamente, hay una forma más sencilla de saber si la operación que falló intenta leer la memoria, al menos en x86:
La excepción de falla de página envía un código de error a la pila, que está disponible en el controlador SIGSEGV de Linux como el miembro err de la estructura sigcontext . El bit 1 del código de error es 1 para errores de escritura y 0 en caso contrario. Para la operación de lectura-modificación-escritura, será 0 inicialmente (aquí puede emular la lectura, sabiendo exactamente lo que sucederá).