assembly - online - solidity español

La dirección de devolución incorrecta es POPed después de la llamada SVC

Question

Estoy trabajando en un núcleo ARM Cortex-A5 de un procesador personalizado y estoy obteniendo un problema realmente extraño que parece ser inexplicable desde el punto de vista de SW. El problema es que, en algún momento, al realizar pruebas de estrés en el sistema (reiniciar cientos de veces), a veces se produce un aborto de captura previa al regresar de alguna llamada SVC. Las llamadas se implementan de la siguiente manera:

Código de modo de usuario:

;...Stuff
    BL       foo
;.. Stuff.

foo
    PUSH     {r4,lr}
    SVC      #0x1a 
    POP      {r4,pc}

Controlador SVC:

SVC_Handler
    PUSH     {r0-r12,lr}
    ;... Do stuff
    POP      {r0-r12,lr}
    SUBS     pc,lr,#0

Cuando se produce el aborto, LR_USR apunta a la instrucción junto a BL foo , pero IFAR tiene un valor de cero así como r4 . Entonces, LR_ABT tiene un valor de 0x4 , lo que tiene sentido si tratamos de ramificar a la dirección cero. Dadas estas observaciones, parece que la instrucción POP {r4,pc} está obteniendo dos ceros de la pila en lugar de los valores correctos, que están en la pila en las posiciones correctas observadas con el depurador después de que se produce el aborto (son dos palabras sobre el SP_USR ). Entonces parece que la pila se actualiza con los valores correctos después de que la instrucción pop está sucediendo, o que la instrucción POP tiene errores.

Vale la pena señalar que el código y la pila están en una memoria caché. El modo de usuario y el modo SVC tienen pilas distintas.

¿Puede este efecto explicarse desde el punto de vista de SW o es probable que sea un error de hardware (controlador de memoria / caché?). ¿Alguien ha visto algo similar en su carrera? Desafortunadamente, es posible depurar solo post-mortem . E instrumentar el código está cambiando el error a otra llamada (Sí, es Heisenbug ...)