Linker Script - Secciones de memoria en un script de enlazado (linker script)

🔧 Linker Script: Nomenclatura y Cómo Crear Uno

🧱 Nomenclatura Básica

ENTRY(_start)             /* Punto de entrada */
MEMORY
{
  FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 256K
  RAM (rwx)  : ORIGIN = 0x20000000, LENGTH = 64K
}

SECTIONS
{
  .text : {
    *(.text)           /* Código */
    *(.text*)          /* Más código */
    *(.rodata)         /* Datos de solo lectura */
  } > FLASH

  .data : {
    *(.data)           /* Variables inicializadas */
  } > RAM AT > FLASH

  .bss : {
    *(.bss)            /* Variables no inicializadas */
    *(COMMON)
  } > RAM
}

🧩 Paso a Paso para Crear un Linker Script

1. Define el punto de entrada:
   ENTRY(_start)
2. Declara la memoria disponible:

   MEMORY
   {
     FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 256K
     RAM (rwx)  : ORIGIN = 0x20000000, LENGTH = 64K
   }

3. Organiza las secciones:
   • .text → Código.
   • .data → Variables con valor inicial.
   • .bss → Variables sin valor inicial.
   • .stack, .heap, .isr_vector → Opcionales.
4. Indica en qué memoria va cada sección:
   .text > FLASH
.data > RAM AT > FLASH
5. Incluye secciones adicionales si es necesario: interrupt vector table, stack, heap, etc.
6. Guarda como archivo .ld, por ejemplo: stm32f103.ld
7. Enlaza usando ld o un sistema de compilación como Makefile o CMake.

¿Estás trabajando con algún microcontrolador específico o sistema operativo?

 

 

Uso adecuado de las secciones de memoria en un script de enlazado

El fragmento de código que proporcionaste es un ejemplo de cómo se definen las secciones de memoria en un script de enlazado (linker script). Un script de enlazado le dice al enlazador cómo organizar las diferentes partes de tu programa (código, datos, etc.) en la memoria. 

text       (rx)    : ORIGIN = 0x7C00, LENGTH = 64K
rodata     (r)     : ORIGIN = 0x9000, LENGTH = 32K  /* 32K Mueve rodata fuera de data */
data       (rw)    : ORIGIN = 0xA000, LENGTH = 64K
bss        (rw)    : ORIGIN = 0xB000, LENGTH = 2M    /* Incrementado de 32K a 2MB */
eh_frame   (r)     : ORIGIN = 0xFBA0, LENGTH = 32K  /* 16K Asignación independiente */
got_plt    (rw)    : ORIGIN = 0xFF00, LENGTH = 32K  /* 16K Ubicación separada */

• text (rx):

  • text: Nombre de la sección. Esta sección contiene el código ejecutable de tu programa (instrucciones de la CPU).

  • (rx): Atributos de la sección:

    • r (read): La sección se puede leer.

    • x (execute): La sección se puede ejecutar.

  • ORIGIN = 0x7C00: Dirección de memoria donde se cargará esta sección. En este caso, 0x7C00. Esta es una dirección muy común para el código del bootloader.

  • LENGTH = 64K: Tamaño máximo de la sección, en este caso, 64 kilobytes.

  Uso adecuado: La sección text debe contener solo código ejecutable. Es crucial que esta sección tenga los atributos rx (lectura y ejecución) y que su dirección de origen sea una dirección válida donde el código puede ser cargado y ejecutado por la CPU.

• rodata (r):

  • rodata: Nombre de la sección. Esta sección contiene datos de solo lectura, como cadenas de texto constantes y otros datos que no deberían modificarse durante la ejecución del programa.

  • (r): Atributo de la sección:

    • r (read): La sección solo se puede leer.

  • ORIGIN = 0x9000: Dirección de memoria donde se cargará esta sección.

  • LENGTH = 32K: Tamaño máximo de la sección.

  Uso adecuado: Coloca las constantes y los datos que no cambian en rodata. Esto ayuda al compilador y al sistema operativo a proteger estos datos de modificaciones accidentales, mejorando la estabilidad del programa.

• data (rw):

  • data: Nombre de la sección. Esta sección contiene datos inicializados que pueden ser modificados por el programa (variables globales y estáticas con valores iniciales).

  • (rw): Atributos de la sección:

    • r (read): La sección se puede leer.

    • w (write): La sección se puede escribir.

  • ORIGIN = 0xA000: Dirección de memoria.

  • LENGTH = 64K: Tamaño máximo.

  Uso adecuado: Utiliza la sección data para las variables que tu programa necesita leer y modificar.

• bss (rw):

  • bss: Nombre de la sección. Esta sección contiene variables globales y estáticas que no están inicializadas explícitamente. El sistema operativo inicializa estas variables a cero antes de que el programa comience a ejecutarse.

  • (rw): Atributos de la sección:

    • r (read): La sección se puede leer.

    • w (write): La sección se puede escribir.

  • ORIGIN = 0xB000: Dirección de memoria.

  • LENGTH = 2M: Tamaño máximo.

  Uso adecuado: Define las variables no inicializadas en la sección bss. Es importante reservar suficiente espacio para estas variables, ya que si se desborda esta sección, puede corromperse la memoria del programa. En este ejemplo, se ha incrementado el tamaño de bss de 32KB a 2MB, lo que proporciona mucho más espacio para las variables no inicializadas.

• eh_frame (r):

  • eh_frame: Nombre de la sección. Esta sección contiene información para el manejo de excepciones, como el rastreo de la pila.

  • (r): Atributo de la sección:

    • r (read): La sección se puede leer.

  • ORIGIN = 0xFBA0: Dirección de memoria.

  • LENGTH = 32K: Tamaño máximo.

  Uso adecuado: La sección eh_frame es importante para la correcta gestión de excepciones en C++ y otros lenguajes que las utilizan. Colócala en una región de memoria que no se superponga con otras secciones y que sea accesible en tiempo de ejecución.

• got_plt (rw):

  • got_plt: Nombre de la sección. Esta sección se utiliza para la vinculación dinámica de funciones de bibliotecas compartidas.

  • (rw): Atributos de la sección:

    • r (read): La sección se puede leer.

    • w (write): La sección se puede escribir.

  • ORIGIN = 0xFF00: Dirección de memoria.

  • LENGTH = 32K: Tamaño máximo.

  Uso adecuado: La sección got_plt es esencial para los programas que utilizan bibliotecas dinámicas. Debe colocarse en una ubicación que permita tanto la lectura como la escritura por parte del enlazador dinámico y el programa en tiempo de ejecución.

Consideraciones importantes

• Superposición de memoria: Es crucial que las secciones no se solapen en la memoria. El enlazador utiliza las direcciones de origen y las longitudes para asignar espacio a cada sección. Si hay superposiciones, el programa puede fallar o comportarse de manera impredecible.
• Direcciones de memoria válidas: Las direcciones de origen deben ser direcciones de memoria válidas para la plataforma en la que se está ejecutando el programa. Por ejemplo, en un sistema embebido, ciertas áreas de memoria pueden estar reservadas para hardware o firmware.
• Tamaños de sección adecuados: Los tamaños de las secciones deben ser lo suficientemente grandes como para contener todos los datos que se van a colocar en ellas. Si una sección es demasiado pequeña, el enlazador generará un error o los datos se escribirán fuera de los límites de la sección, lo que puede provocar corrupción de la memoria.
• Atributos de sección correctos: Los atributos de cada sección deben configurarse correctamente. Por ejemplo, intentar ejecutar código desde una sección marcada como solo de lectura (r) provocará un error.
• Script de enlazado: Estas definiciones de sección suelen estar contenidas en un archivo de script de enlazado (linker script), que se utiliza como entrada para el enlazador. El script de enlazado proporciona un control detallado sobre cómo se organiza la memoria del programa.

 
 
 

script de Linker

Como hemos leído anteriormente, el código de inicio necesita saber algo de información sobre el diseño de la memoria, específicamente el comienzo y el final de secciones de datos y bss, y el inicio de la inicialización datos en ROM.

Esta información es proporcionada por el enlazador cuando combina todo archivos de objetos para producir el binario final. Pero el diseño de la memoria es muy dependiente de la plataforma, ya que no todos los dispositivos tienen flash y RAM en los mismos lugares.

La elegante manera elegida por las herramientas gcc y gnu para manejar esto es a través de scripts de enlace; uno o más archivos de texto que describen la particularidades del diseño de la memoria, colocación de secciones y otros información requerida para producir el ejecutable final.

Una revisión rápida

El proceso de construcción de la herramienta gnu es el siguiente:

• Todos *.c archivos se construyen individualmente a un archivo objeto *.o. Estos archivos son una recopilación de secciones que contienen datos binarios de tipos de diferentes:
  • El código de cada archivo C genera el .textSección
  • Los datos de la lectura generan el .rodataSección
  • Los datos no cero inicializados generan el .dataSección
  • Los datos cero inicializados generan el .bssSección
  • Los datos no fijos generan el COMMONSección. C mandatos estándar para que se rubrice como 0 como .bssSección. Debido a esto, algunos compiladores sólo generan un .bssSección unirse a ambos .bssy COMMONsecciones.
• El enlazador se une a las secciones de objetos individuales y coloca secciones unidas en direcciones específicas dependiendo del diseño del script del enlace.
• Si no proporcionamos un script de enlazador, la cadena de herramientas proporciona uno por defecto. Normalmente, este script no es adecuado para usar en dispositivos metálicos desnudos.

El script de enlace consiste en comandos para describir la colocación de la secciones diferentes en el área de la memoria.

script de enlazador básico

En el siguiente código, podemos ver un script de enlazador funcional completo compatible con la startup expuesta en las últimas secciones:

/* Start of section description layout */
SECTIONS
{
  . = 0x08000000; /* The dot is current address counter. */

  /* If you do not specify any, start at 0 */
  .text : {
    /* KEEP keyword is used to  ensure that symbols are not discarded if the 
       linker is instructed to remove unused symbols. */
    KEEP(*(.vector_core*)) /* Place .vector_core at start of ROM */
    *(.text)   /* Place all symbols in ".text" section */
    *(.text.*)  /* Place all symbols that start with section ".text.<any>" */
  }

  /* In many platforms, the linker script puts the .rodata in .text if
     the corresponding section does not exist */
  .rodata : {
    . = ALIGN(4); /* Ensure word alignment of sections */
    *(.rodata)
    *(.rodata*)
    . = ALIGN(4); /* Ensure word alignment of sections */
  }

  .init_array : {
    . = ALIGN(4); /* Ensure word alignment of sections */
    __init_array_start = .;
    /* SORT function sorts the symbols listed in alphabetical order.
       This is required to meet with the initialization order.
       All symbols are in the form of .init_array.0000_nameofsymbol
       when 0000 is replaced by a priority number that can be specified
       at compile time. */
    KEEP(*(SORT(.init_array.*)))
    KEEP(*(.init_array))
    . = ALIGN(4); /* Ensure word alignment of sections */
    __init_array_end = .;
  }

  _etext = .; /* You can define symbols with any expression using dot */

  . = 0x20000000;
  /* AT(expr) is used to specify load address */
  .data : AT(_etext) {
    _data = .;
    *(.data)
    *(.data*)
    . = ALIGN(4);
    _edata = .;
  }

  /* The function LOADADDR returns the load address of a specific section */
  _data_loadaddr = LOADADDR(.data);

  .bss : {
    . = ALIGN(4); /* Ensure word alignment of sections */
    _bss = .;
    *(.bss)
    *(.bss*)
    *(COMMON)
    . = ALIGN(4);
    _ebss = .;
  }

  /* You use prefixes like K to multiply by 1024 or M to multiply for 1048576 */
  _stack = 0x20000000 + 20K; /* Put the stack at end of ram (20K in this example) */
}

La única magia no visible en este guión es la AT(_etext)la expresión. Esto instruye al enlazador a poner la sección en una dirección de carga específica, pero para el este mapa a la dirección actual de puntos. Esto está diseñado específicamente para colocar los datos inicializados en ROM y copiar estos datos a la RAM en el inicio.

Este script de enlace supone que la memoria rom comienza en 0x08000000 y el ariete la dirección comienza en 0x20000000 y finaliza 8K más tarde (el caso más común es el azulgrana procesador stm32f103cb)

Mejorando los scripts con azúcar sintaxis

Podemos mejorar el script añadiendo más constantes amigables con el usuario:

ROM_BASE = 0x08000000;
RAM_BASE = 0x20000000;
RAM_SIZE = 20K;

/* Start of section description layout */
SECTIONS
{
  . = ROM_BASE;
  
  ...

  . = RAM_BASE;
  /* AT(expr) is used to specify load address */
  .data : AT(_etext) {
    _data = .;

  ...

  _stack = RAM_BASE + RAM_SIZE;
}

O mover esto a otro archivo dependiente de plataforma:

INCLUDE(memory.ld)

/* Start of section description layout */
SECTIONS
{
  . = ROM_BASE;
  ...

/* Platform dependent memory.ld */
ROM_BASE = 0x08000000;
RAM_BASE = 0x20000000;
RAM_SIZE = 20K;

Pero la manera realmente bonita de poner secciones diferentes en áreas de memoria es a través de la MEMORYcomando. Usted puede reemplazar el contenido de memory.ldcon:

MEMORY {
  rom rx : ORIGIN 0x08000000, LENGTH = 64K
  ram rwx : ORIGIN 0x20000000, LENGTH = 20K
}

Ahora el script del enlazador necesita algunos cambios para usar las regiones de memoria adecuado:

INCLUDE memory.ld

SECTIONS
{
  .text : {
    KEEP(*(.vector_core*))
    *(.text)
    *(.text.*)
  } > rom /* fill rom memory area with .text section */

  .rodata : {
    . = ALIGN(4);
    *(.rodata)
    *(.rodata*)
    . = ALIGN(4);
  } > rom /* the second >rom appends the current block to previous block */

  .init_array : {
    . = ALIGN(4);
    __init_array_start = .;
    KEEP(*(SORT(.init_array.*)))
    KEEP(*(.init_array))
    . = ALIGN(4);
    __init_array_end = .;
  } > rom

  .data : {
    _data = .;
    *(.data)
    *(.data*)
    . = ALIGN(4);
    _edata = .;
  } > ram AT>rom /* AT>section is to append in load memory address mode */

  _data_loadaddr = LOADADDR(.data);

  .bss : {
    . = ALIGN(4);
    _bss = .;
    *(.bss)
    *(.bss*)
    *(COMMON)
    . = ALIGN(4);
    _ebss = .;
  } > ram

  /* ORIGIN(region) returns the address of memory region, LENGTH returns the length */
  _stack = ORIGIN(ram) + LENGTH(ram);
}

Este truco tiene algunas ventajas:

• El enlazador puede comprobarlo automáticamente cuando una sección de memoria se agota y termina con un error
• No necesitamos mantener el puntero de punto en el valor correcto
• El script del enlace se explica automáticamente dónde está su código
• Nuevas versiones de ld pueden mostrar el consumo de memoria para todas las áreas de memoria de una manera fácil de usar

El último punto se puede ilustrar con el volcado del comando de la continuación:

Memory region         Used Size  Region Size  %age Used
             rom:         220 B        64 KB      0.34%
             ram:          12 B        20 KB      0.06%

El siguiente paso es construir todo con un guión Makefile y producir la final ejecutable, adecuado para ser enviado a la memoria ROM...

Leer más: 

• https://users.informatik.haw-hamburg.de/~krabat/FH-Labor/gnupro/5_GNUPro_Utilities/c_Using_LD/ldLinker_scripts.html
• https://ourembeddeds.github.io/blog/2020/09/21/arm7m-startup-ldscript/ 
• https://mcuoneclipse.com/2014/10/06/putting-code-of-files-into-special-section-with-the-gnu-linker/