assembly - El contador de programa cambia de forma extraña sin ninguna instrucción que lo modifique(qemu-arm, bare metal)

segmentation-fault gdb

Question

Actualmente estoy tratando de hacer que un programa que escribí se ejecute en un dispositivo de brazo metálico desnudo. Como no tengo el dispositivo (todavía), intento ejecutar el código en una emulación de brazo con qemu.

ejecuto mi código con este comando: qemu-system-arm -M realview-pb-a8 -m 128M -nographic -s -S -kernel myprog .

La ejecución se bloquea siempre en el mismo punto, incluso si utilizo otras configuraciones de la placa. Este es el lugar donde se queda atascado (alguna pieza de código openSSL):

 0x398b4 <EVP_CipherInit_ex+884> ldr r3, [r11, #-24]
0x398b8 <EVP_CipherInit_ex+888> ldr r3, [r3]
0x398bc <EVP_CipherInit_ex+892> ldr r12, [r3, #20]
0x398c0 <EVP_CipherInit_ex+896> ldr r0, [r11, #-24]
0x398c4 <EVP_CipherInit_ex+900> ldr r1, [r11, #-36] ; 0x24
0x398c8 <EVP_CipherInit_ex+904> ldr r2, [r11, #4]
0x398cc <EVP_CipherInit_ex+908> ldr r3, [r11, #8]
0x398d0 <EVP_CipherInit_ex+912> mov lr, pc
0x398d4 <EVP_CipherInit_ex+916> bx r12
[..]
-> 0x391e4 <aes_init_key> push {r11, lr} <- Strange thing happens at this instruction.
0x391e8 <aes_init_key+4> add r11, sp, #4
0x391ec <aes_init_key+8> sub sp, sp, #40 ; 0x28
0x391f0 <aes_init_key+12> str r0, [r11, #-24]
0x391f4 <aes_init_key+16> str r1, [r11, #-28]

Justo después de la instrucción en 0x391e4, $ pc cambia a 0x391e6 en lugar de 0x391e8. Esta no es una dirección válida, por lo que salta directamente al principio del archivo en la ejecución. Si cambio $ pc al valor correcto en el depurador llego a 0x391e8 pero el $ pc se establece nuevamente en un valor incorrecto (0x391ea). No pude reproducir este comportamiento con otro código que no sea el mío.

Aquí hay un volcado de los registros principales justo antes de que suceda.

r0 0xe28db004 -494030844 r1 0x7aeb8 503480
r2 0x7aea8 503464 r3 0x1 1
r4 0x7df98 515992 r5 0x7dfa8 516008
r6 0x0 0 r7 0x0 0
r8 0x0 0 r9 0x0 0
r10 0x60000 393216 r11 0x7ae34 503348
r12 0x391e5 233957 sp 0x7ae08 0x7ae08 <__malloc_av_+252>
lr 0x398d8 235736 pc 0x391e6 0x391e6 <aes_init_key+2>
cpsr 0x200001f3 536871411

Y aquí uno justo después:

r0 0xe28db004 -494030844 r1 0x7aeb8 503480
r2 0x7aea8 503464 r3 0x1 1
r4 0x7df98 515992 r5 0x7dfa8 516008
r6 0x0 0 r7 0x0 0
r8 0x0 0 r9 0x0 0
r10 0x60000 393216 r11 0x7ae34 503348
r12 0x391e5 233957 sp 0x7e000 0x7e000
lr 0x391e8 233960 pc 0x8 0x8
cpsr 0x200001db 536871387

Cómo puedo resolver este problema? ¿Podría ser esto un error del compilador?

-marm estas banderas del compilador: -marm -mthumb-interwork

Answer 1

El cambio de 2 bytes suena sospechosamente como el modo pulgar y, de hecho, su bit cpsr # 5 está configurado. O bien, este es realmente el código de pulgar, en cuyo caso lo está desmontando incorrectamente, o es código de armado, en cuyo caso se denomina erróneamente en el modo de pulgar.