none - https launchpad net gcc arm embedded

¿Por qué arm-none-eabi-size informa que la sección.data es 0 aunque estoy usando RAM inicializada?

Question

Estoy un poco confundido por los resultados que obtengo cuando uso la utilidad de tamaño de mi toolchain (Yagarto y codesourcery). informa que estoy usando 0 bytes en la sección de datos. vea abajo

$ arm-none-eabi-size.exe rest-server-example.crazy-horse.elf
   text    data     bss     dec     hex filename
  79364       0   34288  113652   1bbf4 rest-server-example.crazy-horse.elf

Sé que mi código está usando e inicializando variables de RAM estática a valores distintos de 0.

Curiosamente, cuando paso la herramienta de tamaño directamente a algunos de los archivos de objeto que están siendo vinculados veo que se informa la sección de datos.

ejemplo:

   text    data     bss     dec     hex filename
   1648       0      20    1668     684 obj_crazy-horse/uip-nd6.o
    200      12    2652    2864     b30 obj_crazy-horse/uip-packetqueue.o
     12       0       0      12       c obj_crazy-horse/uip-split.o
   1816      24      48    1888     760 obj_crazy-horse/usb-core.o
    284       0       0     284     11c obj_crazy-horse/usb-interrupt.o
   2064      20     188    2272     8e0 obj_crazy-horse/xmac.o

¿Por qué el archivo elf informa 0 para la sección .data cuando los archivos de objeto que lo hacen están informando valores distintos de cero?

FYI Estoy trabajando en un software integrado para un Micro AT91SAM7x256

editar:

agregando los CFLAGS y LDFLAGS

CFLAGS  += -O -DRUN_AS_SYSTEM -DROM_RUN  -ffunction-sections

LDFLAGS += -L $(CPU_DIRECTORY) -T $(LINKERSCRIPT) -nostartfiles -Wl,-Map,$(TARGET).map

edición n. ° 2: desde el volcado de objetos podemos ver claramente que la sección .data tiene datos asignados, pero la utilidad de tamaño no la está recogiendo por algún motivo objdump link

Todo lo que estoy buscando es obtener un uso exacto de mi RAM. No estoy tratando de averiguar si una de mis variables fue optimizada.

edición 3: más información que muestra que la herramienta de tamaño ve algo en la sección .data

$ arm-none-eabi-size.exe -A -t -x  rest-server-example.crazy-horse.elf
rest-server-example.crazy-horse.elf  :
section              size       addr
.vectrom             0x34   0x100000
.text             0x10fc8   0x100038
.rodata            0x149c   0x111000
.ARM.extab           0x30   0x11249c
.ARM.exidx           0xe0   0x1124cc
.data              0x1028   0x200000
.bss               0x7bec   0x201028
.stack              0xa08   0x20f5f8
.ARM.attributes      0x32        0x0
.comment             0x11        0x0
.debug_aranges      0xc68        0x0
.debug_info       0x2b87e        0x0
.debug_abbrev      0x960b        0x0
.debug_line        0x9bcb        0x0
.debug_frame       0x4918        0x0
.debug_str         0x831d        0x0
.debug_loc        0x13fad        0x0
.debug_ranges       0x620        0x0
Total             0x7c4c5

Answer 1

Mi interpretación sería que el script del enlazador crea una única sección cargable, que contiene los valores iniciales de la sección de datos y una parte del código de inicio que copia los datos en la sección de datos no inicializados.

Esto es necesario si desea tener un solo archivo de imagen que pueda ejecutarse desde la memoria de solo lectura, ya que no hay un cargador ELF en frente que realice esa copia por usted.

Normalmente, esto solo se realiza en la sección de asignación de segmentos (es decir, las secciones de salida se organizan en el script del enlazador utilizando el comando > placement) en lugar de mapear la sección de entrada dos veces, pero eso también es posible.

Los números de uso son bastante precisos: el tamaño del texto es la cantidad de espacio de flash necesaria, el tamaño del BSS es la cantidad de RAM necesaria. Los datos inicializados se cuentan dos veces, una para los datos iniciales en Flash y una para los datos modificables en la memoria RAM.

Answer 2

Su sección .data tiene el atributo CODE establecido, y esto confunde "arm-none-eabi-size". El tamaño de la sección .data se agrega incorrectamente al tamaño de texto total en lugar del tamaño de datos.

Supongo que tiene algún código que está almacenado en flash pero que se copia para ejecutar en tiempo de ejecución, como un controlador de interrupción rápido o reprogramación flash que debe ejecutarse desde la RAM. Esto establecerá el atributo CÓDIGO para el segmento de datos, y "tamaño" cree que todos los datos son texto.