FAST-OS Topics

This appendix describes topics relevant to GNAT Pro for FAST-OS, an embedded operating system maintained by Thales.

Building a FAST-OS Application

To use GNAT Pro for FAST-OS the environment variable ENV_PREFIX needs to be set to the path containing the libraries of your target. A typical ENV_PREFIX would contain the following directories:

$ENV_PREFIX:
 |--> include:
 |--> lib:
 \--> modules:
       |--> include:
       \--> lib:

Once ENV_PREFIX is set, you may build the basic Hello world example that you may find in file:<gnat installation>/share/examples/gnat/starter. Invoke gprbuild with the following options:

$ gprbuild --target=aarch64-thales-fastos hello.adb

Debugging an Application on FAST-OS

This section describes the steps needed to run the FAST-OS debugger.

The debugging solution that GNAT provides on this target consists of three tools:

  • gdbserver: A debugging server on target, which provides a low-level interface to control the debugged program. This tool is provided by FAST-OS.

  • gdb: The debugger itself, run on the host; it connects to GDBserver and allows the user to control the debugged program through a command-line interface.

  • gnatstudio: GNAT Studio, which provides a graphical front-end for gdb.

To start a debugging session, you first need to start the program under control of GDBserver. For example, if the board has an internet connection to the development host, and assuming the Internet hostname of the board is myboard, your application is named myapp, and the port on which GDBserver will wait for requests is port 2345, the command would be:

myboard> gdbserver myboard:2345 myapp

This starts the execution of your program on the target, and then suspends it at the very beginning. Once this is done, GDBserver then waits for the debugger to connect.

You can now start the debugger. In GNAT Studio, in the Languages tab of the project properties page, you would specify the name of the debugger (e.g. aarch64-thales-fastos-gdb). You would then be able to start this debugger with the command: Debug => Initialize => <No Main Program>. Alternatively, you can run the debugger gdb from the command line.

You are now ready to connect the debugger to the GDB server:

(gdb) target remote myboard:2345

Once the debugger is connected to the GDBserver, you can debug your program as usual (insert breakpoints, inspect variables and memory, etc); remember that the program’s execution has already been started by GDBserver, and thus use “continue” to resume the program’s execution, rather than “run”. Below is an example of a debugging session where the user is interested in debugging a function called some_function, and therefore, after connecting to the target, inserts a breakpoint and then resumes his program until reaching that breakpoint:

(gdb) target remote myboard:2345
   ...
(gdb) break some_function
   ...
(gdb) continue
   ...

For further information about the debugger or the GDB server, please refer to the GDB User’s Manual.

Known Limitations on FAST-OS

Ada’s Annex D for real-time systems is only partially supported on FAST-OS: since FAST-OS does not support PTHREAD_PRIO_PROTECT, Priority Ceiling locking is not supported.

C++ extensions for networking are not implemented on FAST-OS; a few features are missing in FAST-OS to be able to provided, the main ones being:

  • IPv6

  • getaddrinfo

  • gethostname

  • ECANCELED

A few specificities related to shared/static library support:

  • -static: this option would not work on his own; libc and libkernel would need to be kept as shared libraries. This can be achieved by the following linker options: -Wl,--push-state,-Bdynamic,-lc,-lkernel,--pop-state.

  • -gc-sections incompatible with -static: the libraries provided by FAST-OS are built with an older binutils which does not add the linked-to flag to __patchable_function_entries section. This prevents -gc-sections to work correctly with GNAT.

  • C++ locale requires -fPIC.

FAST-OS gdbserver comes with a set of limitation that would show up on the debugger side:

  • shared libraries: The FAST-OS gdbserver does not support the debugging of shared libraries.

  • signals and stack checking: The FAST-OS gdbserver would suspend the debuggee on every signal except SIGUSR1 and SIGUSR2; in practise, this means that the debuggee cannot be resumed once a signal has been hit. Note that this also impacts stack checking: when a stack overflow is detected, a signal is raised.

  • Set register values and inferior function calls: The FAST-OS gdbserver does not allow the debugger to change registers. As a consequence, inferior function calls are not supported.