ventajas variable una son qué que publicas locales las hay globales estaticas entre ejemplos diferencia desventajas arm static-variables relocation fpic

arm - una - Problemas con variables locales estáticas con código reubicable



variables locales pdf (2)

Creo que he repetido lo que estás viendo:

statloc.c unsigned int glob; unsigned int fun ( unsigned int a ) { static unsigned int loc; if(a==0) loc=7; return(a+glob+loc); }

arm-none-linux-gnueabi-gcc -mcpu=cortex-m3 -Wall -Werror -O2 -nostdlib -nostartfiles -ffreestanding -mthumb -fpic -pie -S statloc.c

Lo que da:

.cpu cortex-m3 .fpu softvfp .thumb .text .align 2 .global fun .thumb .thumb_func fun: ldr r3, .L6 .LPIC2: add r3, pc cbnz r0, .L5 ldr r1, .L6+4 movs r2, #7 .LPIC1: add r1, pc ldr ip, .L6+8 str r2, [r1, #0] ldr r1, [r3, ip] ldr r3, [r1, #0] adds r0, r0, r3 adds r0, r0, r2 bx lr .L5: ldr ip, .L6+8 ldr r2, .L6+12 ldr r1, [r3, ip] .LPIC0: add r2, pc ldr r2, [r2] ldr r3, [r1, #0] adds r0, r0, r3 adds r0, r0, r2 bx lr .L7: .align 2 .L6: .word _GLOBAL_OFFSET_TABLE_-(.LPIC2+4) .word .LANCHOR0-(.LPIC1+4) .word glob(GOT) .word .LANCHOR0-(.LPIC0+4) .size fun, .-fun .comm glob,4,4 .bss .align 2 .LANCHOR0 = . + 0 .type loc.823, %object .size loc.823, 4 loc.823: .space 4

También agregué código de inicio y compilé un archivo binario y lo desensamblé para comprender mejor y verificar lo que está sucediendo.

this is the offset from the pc to the .got ldr r3, .L6 add pc so r3 holds a position independent offset to the .got add r3, pc offset in the got for the address of the glob ldr ip, .L6+8 read the absolute address for the global variable from the got ldr r1, [r3, ip] finally read the global variable into r3 ldr r3, [r1, #0] this is the offset from the pc to the static local in .bss ldr r2, .L6+12 add pc so that r2 holds a position independent offset to the static local in .bss add r2, pc read the static local in .bss ldr r2, [r2]

Por lo tanto, si cambiara el lugar donde está cargado .text y cambiara donde se carguen tanto .got como .bss en relación con .text y eso es todo, entonces el contenido de .got sería incorrecto y la variable global se cargaría desde el Lugar equivocado.

si tuviera que cambiar donde se carga .text, deje .bss donde el enlazador lo puso y mueva .got relativo a .text. entonces el global sería sacado del lugar correcto y el local no lo haría

si tuviera que cambiar el lugar donde se carga .text, cambie dónde se cargan .got y .bss en relación con .text y modifique los contenidos .got para reflejar dónde se carga .text, luego se accederá a la variable local y global desde el lugar correcto.

Por lo tanto, el cargador y gcc / ld deben estar sincronizados. Mi recomendación inmediata es no utilizar un local estático y solo usar un global. Eso o no preocuparse por el código de posición independiente, es un cortex-m3 después de todo y un tanto limitado en recursos, simplemente defina el mapa de memoria por adelantado. Supongo que la pregunta es cómo hago que gcc use el .got para el local global, y ese no sé la respuesta, pero tomando un ejemplo simple como el anterior, puede trabajar a través de las opciones de la línea de comando hasta que encuentre uno que cambia la salida.

Estoy construyendo un proyecto que tiene código reubicable en metal desnudo. Es una aplicación integrada Cortex M3. No tengo un enlazador dinámico y he implementado todas las reubicaciones en mi código de inicio.

Mayormente está funcionando pero mis variables estáticas locales parecen estar ubicadas incorrectamente. Su dirección se compensa por la cantidad que mi ejecutable se compensa en la memoria, es decir, compilo mi código como si estuviera cargado en la ubicación de la memoria 0, pero en realidad lo cargo en la memoria ubicada en 0x8000. La variable local estática tiene su dirección de memoria compensada por 0x8000, lo cual no es bueno.

Mis variables globales están ubicadas correctamente por el GOT, pero las variables locales estáticas no están en absoluto en el GOT (al menos no aparecen cuando ejecuto readelf -r ). Estoy compilando mi código con -fpic y el enlazador tiene -fpic y -pie especificados. Creo que me falta una opción de compilación y / o enlace para indicar a gcc que use GOT para las variables locales estáticas o para que le indique que use el direccionamiento absoluto para ellas.

Parece que actualmente el código agrega la PC a la ubicación de las variables locales estáticas.