Un desarrollador de un hipervisor bare-metal sobre ARM64 para postmarketOS relata una larga sesión de depuración que comenzó al activar la intercepción del registro CTR_EL0: el teléfono se bloqueaba aleatoriamente y solo el watchdog lo recuperaba. Tras verificar el manejador de excepciones, la pila y los registros conservados, las trazas en hardware revelaron que el manejador no modificaba ningún registro, ni siquiera el de salida previsto. La causa resultó ser la falta de coherencia entre caché de datos y caché de instrucciones en ARM: una rutina C ordenaba en tiempo de ejecución un búfer con instrucciones máquina, así que el procesador ejecutaba código desordenado y obsoleto. Mover la ordenación a la fase de compilación resolvió ese primer misterio, pero el sistema seguía sin arrancar.
La investigación descartó luego fallos del kernel y de /dev/urandom, analizándose el binario con objdump para localizar las 22 instrucciones que leían CTR_EL0. Reescribir en ensamblador, sin acceder a memoria, el manejo de la instrucción mrs x3, ctr_el0 permitió avanzar el arranque hasta adb, confirmando que la lógica era correcta. Un experimento clave dejó claro que una versión C mínima con asm volatile inline funcionaba, pero llamar al accesor mediante un puntero a función calculado a partir de msr_accessors+5 no, lo que apuntaba a un problema de reubicación del enlazador. La historia, publicada por Sonya, ilustra las diferencias entre ARM y x86, las peculiaridades de los diseños de los fabricantes y la utilidad de herramientas como objdump y la instrumentación paso a paso para cazar bugs hardware a muy bajo nivel.