usar - variables locales y globales ventajas y desventajas

Diferentes variables globales estáticas comparten la misma dirección de memoria

Question

Resumen

Tengo varios archivos fuente de C que declaran variables globales estáticas con nombres idénticos. Mi entendimiento es que la variable global estática en cada archivo debe ser visible solo dentro de ese archivo y no debe tener una vinculación externa aplicada, pero de hecho puedo ver al depurar que las variables con nombres idénticos comparten la misma dirección de memoria.

Es como si la palabra clave static se ignorara y las variables globales se trataran como extern . ¿Por qué es esto?

Código de ejemplo

foo.c:

/* Private variables -----------------------------------*/
static myEnumType myVar = VALUE_A;
/* Exported functions ----------------------------------*/
void someFooFunc(void) {
myVar = VALUE_B;
}

bar.c:

/* Private variables -----------------------------------*/
static myEnumType myVar = VALUE_A;
/* Exported functions ----------------------------------*/
void someBarFunc(void) {
myVar = VALUE_C;
}

baz.c:

/* Private variables -----------------------------------*/
static myEnumType myVar = VALUE_A;
/* Exported functions ----------------------------------*/
void someBazFunc(void) {
myVar = VALUE_D;
}

Observaciones de depuración

1. Establezca puntos de interrupción en la línea myVar = ... dentro de cada función.
2. Llame a someFooFunc , someBarFunc y someBazFunc en ese orden desde main.
3. Dentro de someFooFunc myVar inicialmente se establece en VALUE_A , después de pasar sobre la línea, se establece en VALUE_B .
4. Dentro de someBarFunc myVar está, por algún motivo, inicialmente configurado en VALUE_B antes de pasar por encima de la línea, no VALUE_A como esperaría, lo que indica que el vinculador puede haber fusionado las variables globales separadas basándose en que tienen un nombre idéntico.
5. Lo mismo ocurre con someBazFunc cuando se llama.
6. Si uso el depurador para evaluar el valor de &myVar cuando en cada punto de interrupción se da la misma dirección.

Herramientas y banderas

Cadena de herramientas: GNU ARM GCC (6.2 2016q4)

Opciones del compilador:

arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mlong-calls -O1 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -ffreestanding -fno-move-loop-invariants -Wall -Wextra -g3 -DDEBUG -DTRACE -DOS_USE_TRACE_ITM -DSTM32L476xx -I"../include" -I"../system/include" -I"../system/include/cmsis" -I"../system/include/stm32l4xx" -I"../system/include/cmsis/device" -I"../foo/inc" -std=gnu11 -MMD -MP -MF"foo/src/foo.d" -MT"foo/src/foo.o" -c -o "foo/src/foo.o" "../foo/src/foo.c"

Opciones de enlazador:

arm-none-eabi-g++ -mcpu=cortex-m4 -mthumb -mlong-calls -O1 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -ffreestanding -fno-move-loop-invariants -Wall -Wextra -g3 -T mem.ld -T libs.ld -T sections.ld -nostartfiles -Xlinker --gc-sections -L"../ldscripts" -Wl,-Map,"myProj.map" --specs=nano.specs -o ...

Answer 1

Las respuestas hasta ahora han demostrado que deberían funcionar como están escritas, pero la respuesta real está solo en los comentarios, así que la publicaré como respuesta.

Lo que estás viendo es un artefacto depurador, no la situación real. En mi experiencia, esta debe ser su primera suposición de cualquier observación verdaderamente extraña dentro del depurador. Verifique la observación en el programa en ejecución real antes de continuar. Por ejemplo, una antigua declaración de debug printf.

Answer 2

así hace feliz al enlazador

.globl _start
_start: b _start

one.c

static unsigned int hello = 4;
static unsigned int one = 5;
void fun1 ( void )
{
hello=5;
one=6;
}

dos.c

static unsigned int hello = 4;
static unsigned int two = 5;
void fun2 ( void )
{
hello=5;
two=6;
}

tres.c

static unsigned int hello = 4;
static unsigned int three = 5;
void fun3 ( void )
{
hello=5;
three=6;
}

En primer lugar, si optimiza, este es un código completamente muerto y no debe esperar ver ninguna de estas variables. Las funciones no son estáticas por lo que no desaparecen:

Disassembly of section .text:
08000000 <_start>:
8000000: eafffffe b 8000000 <_start>
08000004 <fun1>:
8000004: e12fff1e bx lr
08000008 <fun2>:
8000008: e12fff1e bx lr
0800000c <fun3>:
800000c: e12fff1e bx lr

Si no optimizas entonces

08000000 <_start>:
8000000: eafffffe b 8000000 <_start>
08000004 <fun1>:
8000004: e52db004 push {r11} ; (str r11, [sp, #-4]!)
8000008: e28db000 add r11, sp, #0
800000c: e59f3020 ldr r3, [pc, #32] ; 8000034 <fun1+0x30>
8000010: e3a02005 mov r2, #5
8000014: e5832000 str r2, [r3]
8000018: e59f3018 ldr r3, [pc, #24] ; 8000038 <fun1+0x34>
800001c: e3a02006 mov r2, #6
8000020: e5832000 str r2, [r3]
8000024: e1a00000 nop ; (mov r0, r0)
8000028: e28bd000 add sp, r11, #0
800002c: e49db004 pop {r11} ; (ldr r11, [sp], #4)
8000030: e12fff1e bx lr
8000034: 20000000 andcs r0, r0, r0
8000038: 20000004 andcs r0, r0, r4
0800003c <fun2>:
800003c: e52db004 push {r11} ; (str r11, [sp, #-4]!)
8000040: e28db000 add r11, sp, #0
8000044: e59f3020 ldr r3, [pc, #32] ; 800006c <fun2+0x30>
8000048: e3a02005 mov r2, #5
800004c: e5832000 str r2, [r3]
8000050: e59f3018 ldr r3, [pc, #24] ; 8000070 <fun2+0x34>
8000054: e3a02006 mov r2, #6
8000058: e5832000 str r2, [r3]
800005c: e1a00000 nop ; (mov r0, r0)
8000060: e28bd000 add sp, r11, #0
8000064: e49db004 pop {r11} ; (ldr r11, [sp], #4)
8000068: e12fff1e bx lr
800006c: 20000008 andcs r0, r0, r8
8000070: 2000000c andcs r0, r0, r12
08000074 <fun3>:
8000074: e52db004 push {r11} ; (str r11, [sp, #-4]!)
8000078: e28db000 add r11, sp, #0
800007c: e59f3020 ldr r3, [pc, #32] ; 80000a4 <fun3+0x30>
8000080: e3a02005 mov r2, #5
8000084: e5832000 str r2, [r3]
8000088: e59f3018 ldr r3, [pc, #24] ; 80000a8 <fun3+0x34>
800008c: e3a02006 mov r2, #6
8000090: e5832000 str r2, [r3]
8000094: e1a00000 nop ; (mov r0, r0)
8000098: e28bd000 add sp, r11, #0
800009c: e49db004 pop {r11} ; (ldr r11, [sp], #4)
80000a0: e12fff1e bx lr
80000a4: 20000010 andcs r0, r0, r0, lsl r0
80000a8: 20000014 andcs r0, r0, r4, lsl r0
Disassembly of section .data:
20000000 <hello>:
20000000: 00000004 andeq r0, r0, r4
20000004 <one>:
20000004: 00000005 andeq r0, r0, r5
20000008 <hello>:
20000008: 00000004 andeq r0, r0, r4
2000000c <two>:
2000000c: 00000005 andeq r0, r0, r5
20000010 <hello>:
20000010: 00000004 andeq r0, r0, r4

hay tres variables de saludo creadas (ya debe notar que no hay ninguna razón para iniciar el depurador; todo esto puede responderse simplemente examinando el compilador y la salida del vinculador, el depurador solo se interpone en el camino)

 800000c: e59f3020 ldr r3, [pc, #32] ; 8000034 <fun1+0x30>
8000034: 20000000 andcs r0, r0, r0
8000044: e59f3020 ldr r3, [pc, #32] ; 800006c <fun2+0x30>
800006c: 20000008 andcs r0, r0, r8
800007c: e59f3020 ldr r3, [pc, #32] ; 80000a4 <fun3+0x30>
80000a4: 20000010 andcs r0, r0, r0, lsl r0
20000000 <hello>:
20000000: 00000004 andeq r0, r0, r4
20000008 <hello>:
20000008: 00000004 andeq r0, r0, r4
20000010 <hello>:
20000010: 00000004 andeq r0, r0, r4

Cada función está accediendo a su propia versión separada del global estático. No se combinan en una global compartida.

Answer 3

NOTA: Entiendo que la plataforma de destino de OP es ARM, pero aún así, estoy publicando una respuesta en términos de x86. La razón es que no tengo ningún backend ARM a mano, mientras que la pregunta no se limita a una arquitectura en particular.

Aquí hay un simple banco de pruebas. Tenga en cuenta que estoy usando int lugar de enum typedef personalizado, ya que no debería importar en absoluto.

foo.c

static int myVar = 1;
int someFooFunc(void)
{
myVar += 2;
return myVar;
}

bar.c

static int myVar = 1;
int someBarFunc(void)
{
myVar += 3;
return myVar;
}

C Principal

#include <stdio.h>
int someFooFunc(void);
int someBarFunc(void);
int main(int argc, char* argv[])
{
printf("%d/n", someFooFunc());
printf("%d/n", someBarFunc());
return 0;
}

Lo estoy compilando en x86_64 Ubuntu 14.04 con GCC 4.8.4:

$ g++ main.c foo.c bar.c
$ ./a.out
3
4

Obtener dichos resultados de manera efectiva significa que myVar variables myVar en foo.c y bar.c son diferentes. Si nos fijamos en el desmontaje (por objdump -D ./a.out ):

000000000040052d <_Z11someFooFuncv>:
40052d: 55 push %rbp
40052e: 48 89 e5 mov %rsp,%rbp
400531: 8b 05 09 0b 20 00 mov 0x200b09(%rip),%eax # 601040 <_ZL5myVar>
400537: 83 c0 02 add $0x2,%eax
40053a: 89 05 00 0b 20 00 mov %eax,0x200b00(%rip) # 601040 <_ZL5myVar>
400540: 8b 05 fa 0a 20 00 mov 0x200afa(%rip),%eax # 601040 <_ZL5myVar>
400546: 5d pop %rbp
400547: c3 retq
0000000000400548 <_Z11someBarFuncv>:
400548: 55 push %rbp
400549: 48 89 e5 mov %rsp,%rbp
40054c: 8b 05 f2 0a 20 00 mov 0x200af2(%rip),%eax # 601044 <_ZL5myVar>
400552: 83 c0 03 add $0x3,%eax
400555: 89 05 e9 0a 20 00 mov %eax,0x200ae9(%rip) # 601044 <_ZL5myVar>
40055b: 8b 05 e3 0a 20 00 mov 0x200ae3(%rip),%eax # 601044 <_ZL5myVar>
400561: 5d pop %rbp
400562: c3 retq

Puede ver que las direcciones reales de las variables estáticas en diferentes módulos son de hecho diferentes: 0x601040 para foo.c y 0x601044 para bar.c Sin embargo, están asociados con un solo símbolo _ZL5myVar , que realmente _ZL5myVar lógica GDB.

Puede verificar que por medio de objdump -t ./a.out :

0000000000601040 l O .data 0000000000000004 _ZL5myVar
0000000000601044 l O .data 0000000000000004 _ZL5myVar

Una vez más, diferentes direcciones, mismos símbolos. Cómo GDB resolverá este conflicto es puramente dependiente de la implementación.

Creo firmemente que es tu caso también. Sin embargo, para estar seguro, es posible que desee probar estos pasos en su entorno.