13. Working in a Cross Environment¶
This chapter explains how to adapt your project and configure GPS when working in a cross environment.
13.1. Customizing your Projects¶
This section describes some possible ways to customize your projects when working in a cross environment. For more details on the project capabilities, see Project Handling.
Two areas of the project editor to modify the project’s properties are particularly relevant to cross environments: the Toolchain page, and the Embedded page.
In the Toolchains page, the toolchains that have been found by GPS while scanning your host are displayed: you can select the one corresponding to your cross environment, or use the + button and manually select the desired cross environment.
If needed, you can also manually modify some of the tools defined in this toolchain in the Tools section of the Toolchains page.
For example, assume you have an Ada project using a Powerpc VxWorks configuration. You should see the toolchain powerpc-wrs-vxworks appear in the Toolchains section. Selecting this toolchain changes the Tools section, displaying the relevant tools (e.g., changing Gnatls to powerpc-wrs-vxworks-gnatls and Debugger to powerpc-wrs-vxworks-gdb).
You can modify the list of toolchains that can be selected when using the + button and their default values via a custom XML file. See Customizing and Extending GPS and in particular Customizing Toolchains for further information.
The Runtimes section allows you to choose a particular runtime for your project. The runtimes that have been found by GPS for the selected toolchain are directly displayed in the combobox. If you want to use a custom runtime (e.g: a runtime which is not packaged with the selected toolchain), specify its path in the combobox’s entry.
To modify your project to support configurations such as multiple targets or multiple hosts, create scenario variables and modify the setting of the Toolchains parameters based on the value of these variables. See Scenarios and Configuration Variables for more information on these variables.
For example, you may want to create a variable called Target
to handle the different kind of targets handled in your project:
Target
Native, Embedded
Target
Native, PowerPC, M68K
Similarly, you may define a Board variable listing the different boards
used in your environment and change the Program host and
Protocol settings accordingly.
In some cases, you may want to provide a different body file for a
specific package (e.g., to handle target-specific differences). A
possible approach in this case is to use a configuration variable
(e.g. called TARGET) and specify a different naming scheme for
this body file (in the project properties Naming tab)
based on the value of TARGET.
13.2. Debugger Issues¶
This section describes debugger issues specific to cross environments. You will find more information on debugging at Debugging.
To automatically connect to the correct remote debug agent when starting a debugging session (using the menu ), be sure to specify the Program host and Protocol project properties, which can be found in the Embedded page. You can also connect (or reconnect) to the remote agent at any time via the menu.
For example, if you are using the Tornado environment, with a target
server called target_ppc, set the Protocol to
wtx and the Program host to target_ppc.
GPS waits for a certain amount of time when trying to connect to a target: if GDB does not asnwer during this time period, GPS interupts the current debugger command and assumes that we failed to connect to the target. You can set this time period with the preference.
To load a new module on the target, select the menu.
If a module has been loaded on the target and is not known to the current debug session, use the menu to load the symbol tables in the current debugger.
For bare-metal development, all these steps can be done at once using the Flash to Board and Debug on Board toolbar buttons. These buttons allow you to build, flash and/or debug your software on the board, spawning the remote debug agent set in the Connection tool project property from the Embedded page. GPS currently supports OpenOCD, st-util and py-ocd as connection tools. You can leave the Connection tool attribute empty if you are using a connection tool that is not supported by GPS: in that case, GPS will still try to connect to the board and everything should work fine if your connection tool has been spawned correctly.