3.15 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 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. The semihosting interface is common across all debug agents provided by ARM. 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.

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. 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.)
  • 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.
How execution gets to this address from the HLT (AArch64) or SVC (AArch32) semihosting instruction depends on the program used, the exception level (EL) 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.
In a mixed AArch64 and AArch32 system, with semihosting used in both execution states, you must arrange for the trapping to occur at a single AArch64 trap address. The AArch64 trap address must be at an exception level that is higher than the AArch32 semihosting calling code because exceptions can only be taken from AArch32 to a higher exception level running in AArch64.


The AArch64 semihosting calling code must be at the same or lower exception level than the AArch64 trap address. For example, EL3 AArch64 startup code that switches to EL2 AArch64 then starts an AArch32 application at EL1 could all make use of a semihosting trap in EL3 AArch64.
Related reference
16.5 About passing arguments to main()
3.16 Working with semihosting
11.42 Debug Configurations - Arguments tab
11.1 App Console view
Related information
DS-5 Debugger commands
Non-ConfidentialPDF file icon PDF versionARM DUI0446W
Copyright © 2010-2015 ARM. All rights reserved.