You copied the Doc URL to your clipboard.

Using semihosting to access resources on the host computer

Semihosting is a mechanism for ARM® targets to communicate input/output requests from application code to a host computer running a debugger.

You can use semihosting to enable the host computer to provide input and output facilities of the final system if your development hardware does not have the necessary facilities. For example, you can use this mechanism to enable functions in the C library, such as printf() and scanf(), to use the screen and keyboard of the host instead of having a screen and keyboard on the target system.

Semihosting implementation on an ARM® processor

Semihosting is implemented by a set of defined software instructions, for example, SVCs, that generate exceptions from program control. The application invokes the appropriate semihosting call and the debug agent then handles the exception. The debug agent provides the required communication with the host. Semihosting uses stack base and heap base addresses to determine the location and size of the stack and heap. The stack base, also known as the top of memory, is an address that is by default 64K from the end of the heap base. The heap base is by default contiguous to the application code.

The following figure shows a typical layout for an ARM target.

Figure 3-10 Typical layout between top of memory, stack, and heap

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.

If you are compiling for the ARMv6-M or ARMv7-M architectures, the Thumb BKPT instruction is used instead of the Thumb SVC instruction. For more information, see: The semihosting interface.)

Semihosting implementation on an ARMv8-A processor

DS-5 supports semihosting for both AArch64 and AArch32 states on both software models and real target hardware. DS-5 Debugger handles semihosting by intercepting HLT 0xF000 in AArch64, or SVC instructions in AArch32 (either SVC 0x123456 in ARM state or SVC 0xAB in Thumb state).

  • For AArch64 code running on real target hardware, the target halts on the HLT instruction and the debugger handles the semihosting automatically.
  • For AArch32 code running on real target hardware or when using a software model in either AArch32 or AArch64 states, you must explicitly set a semihosting trap. Otherwise the debugger reports this error:

    ERROR(TAB180): The semihosting breakpoint address has not been specified.

    This error is reported when the debugger tries to enable semihosting, either when an image is loaded that contains the special symbols __auto_semihosting or __semihosting_library_function, or if you explicitly try to enable semihosting using set semihosting enabled on.

You can set a semihosting trap in the debugger by executing the CLI command: set semihosting vector <trap_address>

This instructs the debugger to set a breakpoint at this address, and when this breakpoint is hit, the debugger takes control to perform the semihosting operation.

For AArch32 state, how execution gets to this address from the SVC semihosting instruction depends on the program used, the Exception level the program is executing at, how exceptions are set up to propagate, and other settings.

It is your responsibility to ensure that execution reaches this address. This is typically done by setting the semihosting vector address to an appropriate offset in the appropriate vector table, or by creating an explicit entry in the vector table that, perhaps conditionally, branches to a known offset.

Related information