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.