You copied the Doc URL to your clipboard.

Bare-metal linking model

Focuses on the conventional embedded market where the whole program, possibly including a Real-Time Operating System (RTOS), is linked in one pass.

Note

This topic includes descriptions of [BETA] features.

The linker can make very few assumptions about the memory map of a bare-metal system. Therefore, you must use the scatter-loading mechanism if you want more precise control. Scatter-loading allows different regions in an image memory map to be placed at addresses other than at their natural address. Such an image is a relocatable image, and the linker must adjust program addresses and resolve references to external symbols.

By default, the linker attempts to resolve all the relocations statically. However, it is also possible to create a position-independent or relocatable image. Such an image can be executed from different addresses and have its relocations resolved at load or run-time. You can use a dynamic model to create relocatable images. A position-independent image does not require a dynamic model.

With the bare-metal model, you can:

  • Identify the regions that can be relocated or are position-independent using a scatter file or command-line options.
  • Identify the symbols that can be imported and exported using a steering file.

You can use the following options with this model:

  • --edit=file_list.
  • --scatter=file.

You can use the following options when scatter-loading is not used:

  • --reloc (not supported in AArch64 state).
  • --ro_base=address.
  • [BETA] --ropi.
  • --rosplit.
  • --rw_base=address.
  • [BETA] --rwpi.
  • --split.
  • --xo_base=address.
  • --zi_base.

Note

--xo_base cannot be used with --ropi or --rwpi.
Was this page helpful? Yes No