In this chapter, you will be presented with a new perspective of the available tool in the Yocto Project. This chapter marks the beginning of the introduction to various tools available in the Yocto Project ecosystem, tools that are very useful and different from the Poky reference system. In this chapter, a short presentation to the Application Development Environment (ADE) is presented with emphasis on the Eclipse project and the Yocto Project's added plug-ins. A number of the plug-ins are shown along with their configurations and use cases.
A broader view of the Application Development Toolkit (ADT) will also be shown to you. This project's main objective is to offer a software stack that is able to develop, compile, run, debug, and profile software applications. It tries to do this without requiring extra learning from the developer's point of view. Its learning curve is very low, taking into consideration the fact that Eclipse is one of the most used Integrated Development Environment (IDEs), and over time, it has become very user-friendly, stable, and dependable. The ADT user experience is very similar to the one that any Eclipse or non-Eclipse user has when they use an Eclipse IDE. The available plug-ins try to make this experience as similar as possible so that development is similar to any Eclipse IDE. The only difference is between configuration steps, and this defines the difference between one Eclipse IDE version and another.
ADT is one of the components of the Yocto Project and provides a cross-development platform, which is perfect for user-specific application development. For the development process to take place in an orderly manner, some components are required:
- Eclipse IDE Yocto plug-ins
- QEMU emulator for specific hardware simulations
- Cross-toolchain alongside its specific
sysroot
, which are both architecture-specific and are generated using the metadata and the build system made available by the Yocto Project - Userspace tools to enhance a developer's experience with the application development process
The QEMU emulator is used to simulate various hardware. It can be obtained with these methods:
- Using the ADT installer script, which offers the possibility of installing it
- Cloning a Poky repository and sourcing the environment, access is granted to a QEMU environment
- Downloading a Yocto release and sourcing the environment offers for the same result
- Installing a cross-toolchain and sourcing the environment to make the QEMU environment available
Before explaining the ADT Project further, its Eclipse IDE plug-ins, other features, and functionalities of the setup would be required. To install the Eclipse IDE, the first step involves the setup of a host system. There are multiple methods to do this:
- Using an ADT install script: This is the recommended method to install the ADT, mostly because the installation process is completely automated. Users are in control of the features that they want available.
- Using the ADT tarball: This method involves a section of an appropriate tarball with the architecture-specific toolchain and setting it up using a script. The tarball can be both downloaded and manually built using Bitbake. This method also has limitations due to the fact that not all of its features are available after installation, apart from the cross-toolchain and QEMU emulator.
- Using a toolchain from the build directory: This method takes advantage of the fact that a build directory is already available, so the setup of the cross-toolchain is very easy. Also, in this case, it faces the same limitation as the one mentioned in the preceding point.
After the host system is prepared with all the required dependencies, the ADT tarball can be downloaded from http://downloads.yoctoproject.org/releases/yocto/yocto-1.7/adt-installer/. At this location, the adt_installer.tar.bz2
archive is available. It needs to be downloaded and its content extracted.
The archive is unpacked using the tar -xjf adt_installer.tar.bz2
command. It can be extracted in any directory, and after unpacking the adt-installer
directory, it is created and contains the ADT installer script called adt_installer
. It also has a configuration file called adt_installer.conf
, which is used to define the configurations before running the script. The configuration file defines information, such as the filesystem, kernel, QEMU support, and so on.
These are the variables that the configuration file contains:
YOCTOADT_REPO
: This defines the packages and root filesystem on which the installation is dependent. Its reference value is defined at http://adtrepo.yoctoproject.org//1.7. Here, the directory structure is defined and its structure is the same between releases.YOCTOADT_TARGETS
: This defines the target architecture for which the cross development environment is set up. There are default values defined that can be associated with this variable, such asarm
,ppc
,mips
,x86
, andx86_64
. Also, multiple values can be associated with it and the separation between them being is done using the space separator.YOCTOADT_QEMU
: This variable defines the use of the QEMU emulator. If it is set toY
, the emulator will be available after installation; otherwise the value is set toN
, and hence, the emulator won't be available.YOCTOADT_NFS_UTIL
: This defines if the NFS user-mode that will be installed. The available values are, as defined previously,Y
andN
. For the use of the Eclipse IDE plug-ins, it is necessary to define theY
value for bothYOCTOADT_QEMU
andYOCTOADT_NFS_UTIL
.YOCTOADT_ROOTFS_<arch>
: This specifies which architecture root filesystem to use from the repository that is defined in the first mentionedYOCTOADT_REPO
variable. For thearch
variable, the default values are the ones already mentioned in theYOCTOADT_TARGETS
variable. This variable's valid values are represented by the image files available, such asminimal
,sato
,minimal-dev
,sato-sdk
,lsb
,lsb-sdk
, and so on. For multiple arguments to the variable, the space separator can be used.YOCTOADT_TARGET_SYSROOT_IMAGE_<arch>
: This represents the root filesystem from which thesysroot
of the cross-development toolchain will be generated. The valid values for the 'arch' variable are the same as the one mentioned previously. Its value is dependent on what was previously defined as values for theYOCTOADT_ROOTFS_<arch>
variable. So, if only one variable is defines as the value for theYOCTOADT_ROOTFS_<arch>
variable, the same value will be available forYOCTOADT_TARGET_SYSROOT_IMAGE_<arch>
. Also, if multiple variables are defined in theYOCTOADT_ROOTFS_<arch>
variable, then one of them needs to define theYOCTOADT_TARGET_SYSROOT_IMAGE_<arch>
variable.YOCTOADT_TARGET_MACHINE_<arch>
: This defines the machine for which the image is downloaded, as there could be compilation option differences between machines of the same architecture. The valid values for this variable are can be mentioned as:qemuarm
,qemuppc
,ppc1022ds
,edgerouter
,beaglebone
, and so on.YOCTOADT_TARGET_SYSROOT_LOC_<arch>
: This defines the location where the targetsysroot
will be available after the installation process.
There are also some variables defined in the configuration files, such as YOCTOADT_BITBAKE
and YOCTOADT_METADATA
, which are defined for future work references. After all the variables are defined according to the needs of the developer, the installation process can start. This is done by running the adt_installer
script:
Here is an example of the adt_installer.conf
file:
After the installation has started, the user is asked the location of the cross-toolchain. If no alternative is offered, the default path is selected and the cross-toolchain is installed in the /opt/poky/<release>
directory. The installation process can be visualized both in a silent or interactive way. By using the I
option, the installation is done in an interactive mode, while the silent mode is enabled using the S
option.
There are two methods to obtain the toolchain installed for this second option. The first method involves the use of the toolchain installer available at http://downloads.yoctoproject.org/releases/yocto/yocto-1.7/toolchain/. Open the folder that matches your development host machine. In this folder, multiple install scripts are available. Each one matches a target architecture, so the right one should be selected for the target you have. One such example can be seen from http://downloads.yoctoproject.org/releases/yocto/yocto-1.7/toolchain/x86_64/poky-glibc-x86_64-core-image-sato-armv7a-vfp-neon-toolchain-1.7.sh, which is, in fact, the installer script for the armv7a
target and the x86_64
host machine.
If your target machine is not one of the ones that are made available by the Yocto community, or if you prefer an alternative to this method, then building the toolchain installer script is the method for you. In this case, you will require a build directory, and you will be presented with two alternatives, both of them are equally good:
- The first one involves the use of the
bitbake meta-toolchain
command, and the end result is an installer script that requires the installation and set up of the cross-toolchain in a separate location. - The second alternative involves the use of the
bitbake –c populate_sdk <image-name>
task, which offers the toolchain installer script and the matchingsysroot
for the target. The advantage here is that the binaries are linked with only one and the samelibc
, making the toolchain self-contained. There is, of course, a limitation that each architecture can create only one specific build. However, target-specific options are passed through thegcc
options. Using variables, such asCC
orLD
, makes the process easier to maintain and also saves some space in the build directory.
With the environment set up, writing of an application can start, but the developer would still need to complete some steps before finishing the activity, such as testing the application on the real root filesystem, debugging, and many others. For the kernel module and driver implementation, the kernel source code will be required, so the activity is just starting.
The plug-ins available for Eclipse from the Yocto Project include the functionalities for the ADT Project and toolchain. They allow developers to use a cross-compiler, debugger, and all the available tools generated with the Yocto Project, Poky, and additional meta layers. Not only can these components be used within the Eclipse IDE, but they also offer a familiar environment for application development.
The Yocto Project offers support for two versions of Eclipse, Kepler and Juno. The Kepler version is the one recommended with the latest Poky release. I also recommend the Kepler 4.3.2 version of Eclipse, the one downloaded from the official download site of Eclipse, http://www.eclipse.org/downloads.
From this site, the Eclipse Standard 4.3.2 version containing the Java Development Tools (JDT), the Eclipse Platform, and the Development Environment Plug-ins for the host machine should be downloaded. After the download is finished, the received archive content should be extracted using the tar command:
To initialize the Eclipse IDE perform the following steps:
- Select Workbench, and you will be moved into the empty workbench where the projects source code will be written.
- Now, navigate through the Help menu and select Install New Software.
- A new window will open, and in the Work with: drop-down menu, select Kepler - http://download.eclipse.org/releases/kepler, as shown in the following screenshot:
- Expand the Linux Tools section and select LTTng – Linux Tracing Toolkit box, as shown in the following screenshot:
- Expand the Moble and Device Development section and select the following:
- C/C++ Remote Launch (Requires RSE Remote System Explorer)
- Remote System Explorer End-user Runtime
- Remote System Explorer User Actions
- Target Management Terminal
- TCF Remote System Explorer add-in
- TCF Target Explorer
- Expand the Programming Languages section and select the following:
- C/C++ Autotools Support
- C/C++ Development Tools
This is shown in the following screenshot:
- Finish the installation after taking a quick look at the Install Details menu and enabling the license agreement:
After these steps, the Yocto Project Eclipse plug-ins can be installed into the IDE, but not before restarting the Eclipse IDE to make sure that the preceding changes take effect. The result after the configuration phase is visible here:
To install the Eclipse plug-ins for the Yocto Project, these steps are required:
- Start the Eclipse IDE as mentioned previously.
- As shown in the previous configuration, select the Install New Software option from the Help menu.
- Click on the Add button and insert
downloads.yoctoproject.org/releases/eclipse-plugin/1.7/kepler/
in the URL section. Give a proper name to the new Work with: site as indicated here: - After the OK button is pressed, and the Work with site is updated, new boxes appear. Select all of them, as shown in this image, and click on the Next button:
- One final pick at the installed components and the installation is approaching its end.
- If this warning message appears, press OK and move further. It only lets you know that the installed packages have unsigned content.
The installation finishes only after the Eclipse IDE is restarted for the changes to take effect.
After the installation, the Yocto plug-ins are available and ready to be configured. The configuration process involves the setup of the target-specific option and cross-compiler. For each specific target, the preceding configurations steps need to be performed accordingly.
The next elements that need to be configured are the toolchain location, sysroot
location, and the target architecture. The Toolchain Root Location is used to define the toolchain install location. For an installation done with the adt_installer
script, for example, the toolchain will be available in the /opt/poky/<release>
directory. The second argument, Sysroot Location, represents the location of the target device root filesystem. It can be found in the /opt/poky/<release>
directory, as seen the preceding example, or even inside the build directory if other method to generate it were used. The third and last option from this section is represented by the Target Architecture and it indicates the type of hardware used or emulated. As it can be seen on the window, it is a pull-down menu where the required option is selected, and a user will find all the supported architectures listed. In a situation where the necessary architecture is not available inside the pull-down menu, the corresponding image for the architecture will need to be built.
To define a project, these steps need to be taken:
- Select the Project… option from the File | New menu option, as shown here:
- Select C project from the C/C++ option. This will open a C Project window:
- In the C Project window, there are multiple options available. Let's select Yocto Project ADT Autotools Project, and from there, the Hello World ANSI C Autotools Project option. Add a name for the new project, and we are ready to move to the next steps:
- In the C Project window we you be prompted to add information regarding the Author, Copyright notice, Hello world greetings, Source, and License fields accordingly:
- After all the information is added, the Finish button can be clicked on. The user will be prompted in the new C/C++ perspective that is specific for the opened project, with the newly created project appearing on the left-hand side of the menu.
- After the project is created and the source code is written, to build the project, select the Build Project option from the Project… menu.
QEMU is used in the Yocto Project as a virtualization machine and emulator for various target architectures. It is very useful to run and test various Yocto generated applications and images, apart from fulfilling other purposes. Its primary use outside of the Yocto world is its selling point for the Yocto Project too, making it the default tool to be used to emulate hardware.
Interaction with the QEMU emulation is done within Eclipse, as shown previously. For this to happen, the proper configuration would be required, as instructed in the preceding section. Starting the QEMU emulation here is done using the External Tools option from the Run menu. A new window will be opened for the emulator, and after the corresponding login information is passed to the prompt, the shell will be available for user interaction. An application can be deployed and debugged on the emulator also.
Debugging an application can also be done using the QEMU emulator or the actual target hardware, if it exists. When the project was configured, a run/debug Eclipse configuration was generated as a C/C+ Remote Application instance, and it can be found on the basis of its name, which is according to the <project-name>_gdb_-<suffix>
syntax. For example, TestProject_gdb_armv5te-poky-linux-gnueabi
could be an example of this.
To connect to the Eclipse GDB interface and start the remote target debugging process, the user is required to perform a few steps:
- Select C/C++ Remote application from the Run | Debug configuration menu and choose the run/debug configuration from the C/C++ Remote Application available in the left panel.
- Select the suitable connection from the drop-down list.
- Select the binary application to deploy. If multiple executables are available in your project, by pushing the Search Project button, Eclipse will parse the project and provide a list with all the available binaries.
- Enter the absolute path in which the application will be deployed by setting the Remote Absolute File Path for C/C++ Application: field accordingly.
- Selecting the debugger option is available in the Debugger tab. To debug shared libraries, a few extra steps are necessary:
- Select the Add | Path Mapping option from the Source tab to make sure a path mapping is available for the debug configuration.
- Select Load shared libraries symbols automatically from the Debug/Shared Library tab and indicate the path of the shared libraries accordingly. This path is highly dependent on the architecture of the processor, so be very careful which library file you indicate. Usually, for the 32-bit architecture, the
lib
directory is selected, and for the 64-bit architecture, thelib64
directory is chosen. - On the Arguments tab, there is a possibility of passing various arguments to the application binary during the time of execution.
- Once all the debug configurations are finished, click on the Apply and Debug buttons. A new GDB session will be launched and Debug perspective will open. When the debugger is being initialized, Eclipse will open three consoles:
- After the setup of the debug configuration, the application can be rebuilt and executed again using the available Debug icon in the toolbar. If, in fact, you want only to run and deploy the application, the Run icon can be used.
Inside the Yocto Tools menu, you can see the supported tools that are used for the tracing and profiling of developed applications. These tools are used for enhancing various properties of the application and, in general, the development process and experience. The tools that will be presented are LTTng, Perf, LatencyTop, PerfTop, SystemTap, and KGDB.
- Start the tracing perspective by selecting Open Perspective from the Window menu.
- Create a new tracing project by selecting Project from the File | New menu.
- Select Control View from the Window | Show view | Other… | Lttng menu. This will enable you to access all these desired operations:
- Creating a new connection
- Creating a session
- Starting/stopping tracing
- Enabling events
Next, we'll introduce the user space performance analyzing tool called Perf. It offers statistical profiling of the application code and a simple CPU for multiple threads and kernel. To do this, it uses a number of performance counters, dynamic probes, or trace points. To use the Eclipse Plug-in, a remote connection to the target is required. It can be done by the Perf wizard or by using the Remote System Explorer | Connection option from the File | New | Other menu. After the remote connection is set up, interaction with the tool is the same as in the case of the command line support available for the tool.
LatencyTop
is an application that is used to identify the latencies available within the kernel and also their root cause. This tool is not available for ARM kernels that have Symmetric multiprocessing (SMP) support enabled due to the limitation of the ARM kernels. This application also requires a remote connection. After the remote connection is set up, the interaction is the same as in the case of the command line support available for the tool. This application is run from the Eclipse Plug-in using sudo
.
PowerTop is used to measure the consumption of electrical power. It analyzes the applications, kernel options, and device drivers that run on a Linux system and estimates their power consumption. It is very useful to identify components that use the most amount of power. This application requires a remote connection. After the remote connection is set up, the interaction with the application is the same as for the command line available support for the tool. This application is run from the Eclipse Plug-in using the –d option to display the output in the Eclipse window.
SystemTap
is a tool that enables the use of scripts to get results from a running Linux. SystemTap provides free software (GPL) infrastructure to simplify the gathering of information about the running Linux system via the tracing of all kernel calls. It's very similar to dtrace from Solaris, but it is still not suited for production systems, unlike dtrace. It uses a language similar to awk
and its scripts have the .stp
extension. The monitored data can be extracted and various filters and complex processing can be done on them. The Eclipse Plug-in uses the crosstap
script to translate the .stp
scripts to a C language to create a Makefile
, run a C compiler to create a kernel module for the target architecture that is inserted into the target kernel, and later, collect the tracing data from the kernel. To start the SystemTap plug-in in Eclipse, there are a number of steps to be followed:
- Select the systemtap option from the Yocto Project Tools menu.
- In the opened windows, the crosstap argument needs to be passed:
- Set the Metadata Location variable to the corresponding
poky
directory - Set Remote User ID by entering the root (the default option) because it has
ssh
access to the target-any other user that has the same privileges is also a good choice - Set in the Remote Host variable to the corresponding IP address for the target
- Use the Systemtap Scripts variable for the full path to the
.stp
scripts - Set additional cross options using the Systemtap Args field
- Set the Metadata Location variable to the corresponding
The output of the .stp
script should be available in the console view from Eclipse.
The last tool we'll take a look at is KGDB. This tool is used specifically for the debugging of Linux kernel, and is useful only if development on the Linux kernel source code is done inside the Eclipse IDE. To use this tool, a number of necessary configuration setups are required:
- Disable the C/C++ indexing:
- Select the C/C++ Indexer option from the Window | Preferences menu
- Unselect the Enable indexer checkbox
- Create a project where the kernel source code can be imported:
- Select the C/C++ | C Project option from the File | New menu
- Select the Makefile project | Empty project option and give a proper name to the project
- Unselect the Use default location option
- Click on the Browse button and identify the kernel source code local git repository location
- Press the Finish button and the project should be created
After the prerequisites are fulfilled, the actual configuration can start:
- Select the Debug Configuration option from the Run menu.
- Double-click on the GDB Hardware Debugging option to create a default configuration named <project name> Default.
- From the Main tab, browse to the location of the
vmlinux
built image, select the Disable auto build radio button, as well as the GDB (DFS) Hardware Debugging Launcher option. - For the C/C++ Application option available in the Debugger tab, browse for the location of the GDB binary available inside the toolchain (if ADT installer script is available, its default location should be
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gdb
). Select Generic serial option from the JTAG Device menu. The Use remote target option is a requirement. - From the Startup tab, select the Load symbols option. Make sure that the Use Project binary option indicates the correct
vmlinux
image and that the Load image option is not selected. - Press the Apply button to make sure the previous configuration is enabled.
- Prepare the target for the serial communication debugging:
- Set the
echo ttyS0,115200
|/sys/module/kgdboc/parameters/kgdboc
option to make sure the appropriate device is used for debugging - Start KGDB on the
echo g
|/proc/sysrq-trigger
target - Close the terminal with the target but keep the serial connectivity
- Set the
- Select the Debug Configuration option from the Run menu
- Select the previously created configuration and click on the Debug button
The bitbake commander offers the possibility of editing recipes and creating a metadata project in a manner similar to the one available in the command line. The difference between the two is that the Eclipse IDE is used to do the metadata interaction.
To make sure that a user is able to do these sort of actions, a number of steps are required:
- Select the Project option from the File | New menu
- Select the Yocto Project BitBake Commander wizard from the opened window
- Select the New Yocto Project option and a new window will be opened tp define properties of the new project
- Using Project Location, identify the parent of the
poky
directory - Use the Project Name option to define the project name. Its default value is poky
- For the Remote service provider variable, select the Local choice and make use of the same choice for the Connection name drop-down list
- Make sure that the Clone checkbox is not selected for an installed
poky
source directory
By using the Eclipse IDE, its features are available to be used. One of the most useful features is the quick search option that could prove to be very useful for some developers. Other benefits include the possibility of creating recipes using templates, editing them with syntax highlighting, auto completion, error reports on the fly, and many more.
used in the Yocto Project as a virtualization machine and emulator for various target architectures. It is very useful to run and test various Yocto generated applications and images, apart from fulfilling other purposes. Its primary use outside of the Yocto world is its selling point for the Yocto Project too, making it the default tool to be used to emulate hardware.
Interaction with the QEMU emulation is done within Eclipse, as shown previously. For this to happen, the proper configuration would be required, as instructed in the preceding section. Starting the QEMU emulation here is done using the External Tools option from the Run menu. A new window will be opened for the emulator, and after the corresponding login information is passed to the prompt, the shell will be available for user interaction. An application can be deployed and debugged on the emulator also.
Debugging an application can also be done using the QEMU emulator or the actual target hardware, if it exists. When the project was configured, a run/debug Eclipse configuration was generated as a C/C+ Remote Application instance, and it can be found on the basis of its name, which is according to the <project-name>_gdb_-<suffix>
syntax. For example, TestProject_gdb_armv5te-poky-linux-gnueabi
could be an example of this.
To connect to the Eclipse GDB interface and start the remote target debugging process, the user is required to perform a few steps:
- Select C/C++ Remote application from the Run | Debug configuration menu and choose the run/debug configuration from the C/C++ Remote Application available in the left panel.
- Select the suitable connection from the drop-down list.
- Select the binary application to deploy. If multiple executables are available in your project, by pushing the Search Project button, Eclipse will parse the project and provide a list with all the available binaries.
- Enter the absolute path in which the application will be deployed by setting the Remote Absolute File Path for C/C++ Application: field accordingly.
- Selecting the debugger option is available in the Debugger tab. To debug shared libraries, a few extra steps are necessary:
- Select the Add | Path Mapping option from the Source tab to make sure a path mapping is available for the debug configuration.
- Select Load shared libraries symbols automatically from the Debug/Shared Library tab and indicate the path of the shared libraries accordingly. This path is highly dependent on the architecture of the processor, so be very careful which library file you indicate. Usually, for the 32-bit architecture, the
lib
directory is selected, and for the 64-bit architecture, thelib64
directory is chosen. - On the Arguments tab, there is a possibility of passing various arguments to the application binary during the time of execution.
- Once all the debug configurations are finished, click on the Apply and Debug buttons. A new GDB session will be launched and Debug perspective will open. When the debugger is being initialized, Eclipse will open three consoles:
- After the setup of the debug configuration, the application can be rebuilt and executed again using the available Debug icon in the toolbar. If, in fact, you want only to run and deploy the application, the Run icon can be used.
Inside the Yocto Tools menu, you can see the supported tools that are used for the tracing and profiling of developed applications. These tools are used for enhancing various properties of the application and, in general, the development process and experience. The tools that will be presented are LTTng, Perf, LatencyTop, PerfTop, SystemTap, and KGDB.
- Start the tracing perspective by selecting Open Perspective from the Window menu.
- Create a new tracing project by selecting Project from the File | New menu.
- Select Control View from the Window | Show view | Other… | Lttng menu. This will enable you to access all these desired operations:
- Creating a new connection
- Creating a session
- Starting/stopping tracing
- Enabling events
Next, we'll introduce the user space performance analyzing tool called Perf. It offers statistical profiling of the application code and a simple CPU for multiple threads and kernel. To do this, it uses a number of performance counters, dynamic probes, or trace points. To use the Eclipse Plug-in, a remote connection to the target is required. It can be done by the Perf wizard or by using the Remote System Explorer | Connection option from the File | New | Other menu. After the remote connection is set up, interaction with the tool is the same as in the case of the command line support available for the tool.
LatencyTop
is an application that is used to identify the latencies available within the kernel and also their root cause. This tool is not available for ARM kernels that have Symmetric multiprocessing (SMP) support enabled due to the limitation of the ARM kernels. This application also requires a remote connection. After the remote connection is set up, the interaction is the same as in the case of the command line support available for the tool. This application is run from the Eclipse Plug-in using sudo
.
PowerTop is used to measure the consumption of electrical power. It analyzes the applications, kernel options, and device drivers that run on a Linux system and estimates their power consumption. It is very useful to identify components that use the most amount of power. This application requires a remote connection. After the remote connection is set up, the interaction with the application is the same as for the command line available support for the tool. This application is run from the Eclipse Plug-in using the –d option to display the output in the Eclipse window.
SystemTap
is a tool that enables the use of scripts to get results from a running Linux. SystemTap provides free software (GPL) infrastructure to simplify the gathering of information about the running Linux system via the tracing of all kernel calls. It's very similar to dtrace from Solaris, but it is still not suited for production systems, unlike dtrace. It uses a language similar to awk
and its scripts have the .stp
extension. The monitored data can be extracted and various filters and complex processing can be done on them. The Eclipse Plug-in uses the crosstap
script to translate the .stp
scripts to a C language to create a Makefile
, run a C compiler to create a kernel module for the target architecture that is inserted into the target kernel, and later, collect the tracing data from the kernel. To start the SystemTap plug-in in Eclipse, there are a number of steps to be followed:
- Select the systemtap option from the Yocto Project Tools menu.
- In the opened windows, the crosstap argument needs to be passed:
- Set the Metadata Location variable to the corresponding
poky
directory - Set Remote User ID by entering the root (the default option) because it has
ssh
access to the target-any other user that has the same privileges is also a good choice - Set in the Remote Host variable to the corresponding IP address for the target
- Use the Systemtap Scripts variable for the full path to the
.stp
scripts - Set additional cross options using the Systemtap Args field
- Set the Metadata Location variable to the corresponding
The output of the .stp
script should be available in the console view from Eclipse.
The last tool we'll take a look at is KGDB. This tool is used specifically for the debugging of Linux kernel, and is useful only if development on the Linux kernel source code is done inside the Eclipse IDE. To use this tool, a number of necessary configuration setups are required:
- Disable the C/C++ indexing:
- Select the C/C++ Indexer option from the Window | Preferences menu
- Unselect the Enable indexer checkbox
- Create a project where the kernel source code can be imported:
- Select the C/C++ | C Project option from the File | New menu
- Select the Makefile project | Empty project option and give a proper name to the project
- Unselect the Use default location option
- Click on the Browse button and identify the kernel source code local git repository location
- Press the Finish button and the project should be created
After the prerequisites are fulfilled, the actual configuration can start:
- Select the Debug Configuration option from the Run menu.
- Double-click on the GDB Hardware Debugging option to create a default configuration named <project name> Default.
- From the Main tab, browse to the location of the
vmlinux
built image, select the Disable auto build radio button, as well as the GDB (DFS) Hardware Debugging Launcher option. - For the C/C++ Application option available in the Debugger tab, browse for the location of the GDB binary available inside the toolchain (if ADT installer script is available, its default location should be
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gdb
). Select Generic serial option from the JTAG Device menu. The Use remote target option is a requirement. - From the Startup tab, select the Load symbols option. Make sure that the Use Project binary option indicates the correct
vmlinux
image and that the Load image option is not selected. - Press the Apply button to make sure the previous configuration is enabled.
- Prepare the target for the serial communication debugging:
- Set the
echo ttyS0,115200
|/sys/module/kgdboc/parameters/kgdboc
option to make sure the appropriate device is used for debugging - Start KGDB on the
echo g
|/proc/sysrq-trigger
target - Close the terminal with the target but keep the serial connectivity
- Set the
- Select the Debug Configuration option from the Run menu
- Select the previously created configuration and click on the Debug button
The bitbake commander offers the possibility of editing recipes and creating a metadata project in a manner similar to the one available in the command line. The difference between the two is that the Eclipse IDE is used to do the metadata interaction.
To make sure that a user is able to do these sort of actions, a number of steps are required:
- Select the Project option from the File | New menu
- Select the Yocto Project BitBake Commander wizard from the opened window
- Select the New Yocto Project option and a new window will be opened tp define properties of the new project
- Using Project Location, identify the parent of the
poky
directory - Use the Project Name option to define the project name. Its default value is poky
- For the Remote service provider variable, select the Local choice and make use of the same choice for the Connection name drop-down list
- Make sure that the Clone checkbox is not selected for an installed
poky
source directory
By using the Eclipse IDE, its features are available to be used. One of the most useful features is the quick search option that could prove to be very useful for some developers. Other benefits include the possibility of creating recipes using templates, editing them with syntax highlighting, auto completion, error reports on the fly, and many more.
To connect to the Eclipse GDB interface and start the remote target debugging process, the user is required to perform a few steps:
- Select C/C++ Remote application from the Run | Debug configuration menu and choose the run/debug configuration from the C/C++ Remote Application available in the left panel.
- Select the suitable connection from the drop-down list.
- Select the binary application to deploy. If multiple executables are available in your project, by pushing the Search Project button, Eclipse will parse the project and provide a list with all the available binaries.
- Enter the absolute path in which the application will be deployed by setting the Remote Absolute File Path for C/C++ Application: field accordingly.
- Selecting the debugger option is available in the Debugger tab. To debug shared libraries, a few extra steps are necessary:
- Select the Add | Path Mapping option from the Source tab to make sure a path mapping is available for the debug configuration.
- Select Load shared libraries symbols automatically from the Debug/Shared Library tab and indicate the path of the shared libraries accordingly. This path is highly dependent on the architecture of the processor, so be very careful which library file you indicate. Usually, for the 32-bit architecture, the
lib
directory is selected, and for the 64-bit architecture, thelib64
directory is chosen. - On the Arguments tab, there is a possibility of passing various arguments to the application binary during the time of execution.
- Once all the debug configurations are finished, click on the Apply and Debug buttons. A new GDB session will be launched and Debug perspective will open. When the debugger is being initialized, Eclipse will open three consoles:
- After the setup of the debug configuration, the application can be rebuilt and executed again using the available Debug icon in the toolbar. If, in fact, you want only to run and deploy the application, the Run icon can be used.
Inside the Yocto Tools menu, you can see the supported tools that are used for the tracing and profiling of developed applications. These tools are used for enhancing various properties of the application and, in general, the development process and experience. The tools that will be presented are LTTng, Perf, LatencyTop, PerfTop, SystemTap, and KGDB.
- Start the tracing perspective by selecting Open Perspective from the Window menu.
- Create a new tracing project by selecting Project from the File | New menu.
- Select Control View from the Window | Show view | Other… | Lttng menu. This will enable you to access all these desired operations:
- Creating a new connection
- Creating a session
- Starting/stopping tracing
- Enabling events
Next, we'll introduce the user space performance analyzing tool called Perf. It offers statistical profiling of the application code and a simple CPU for multiple threads and kernel. To do this, it uses a number of performance counters, dynamic probes, or trace points. To use the Eclipse Plug-in, a remote connection to the target is required. It can be done by the Perf wizard or by using the Remote System Explorer | Connection option from the File | New | Other menu. After the remote connection is set up, interaction with the tool is the same as in the case of the command line support available for the tool.
LatencyTop
is an application that is used to identify the latencies available within the kernel and also their root cause. This tool is not available for ARM kernels that have Symmetric multiprocessing (SMP) support enabled due to the limitation of the ARM kernels. This application also requires a remote connection. After the remote connection is set up, the interaction is the same as in the case of the command line support available for the tool. This application is run from the Eclipse Plug-in using sudo
.
PowerTop is used to measure the consumption of electrical power. It analyzes the applications, kernel options, and device drivers that run on a Linux system and estimates their power consumption. It is very useful to identify components that use the most amount of power. This application requires a remote connection. After the remote connection is set up, the interaction with the application is the same as for the command line available support for the tool. This application is run from the Eclipse Plug-in using the –d option to display the output in the Eclipse window.
SystemTap
is a tool that enables the use of scripts to get results from a running Linux. SystemTap provides free software (GPL) infrastructure to simplify the gathering of information about the running Linux system via the tracing of all kernel calls. It's very similar to dtrace from Solaris, but it is still not suited for production systems, unlike dtrace. It uses a language similar to awk
and its scripts have the .stp
extension. The monitored data can be extracted and various filters and complex processing can be done on them. The Eclipse Plug-in uses the crosstap
script to translate the .stp
scripts to a C language to create a Makefile
, run a C compiler to create a kernel module for the target architecture that is inserted into the target kernel, and later, collect the tracing data from the kernel. To start the SystemTap plug-in in Eclipse, there are a number of steps to be followed:
- Select the systemtap option from the Yocto Project Tools menu.
- In the opened windows, the crosstap argument needs to be passed:
- Set the Metadata Location variable to the corresponding
poky
directory - Set Remote User ID by entering the root (the default option) because it has
ssh
access to the target-any other user that has the same privileges is also a good choice - Set in the Remote Host variable to the corresponding IP address for the target
- Use the Systemtap Scripts variable for the full path to the
.stp
scripts - Set additional cross options using the Systemtap Args field
- Set the Metadata Location variable to the corresponding
The output of the .stp
script should be available in the console view from Eclipse.
The last tool we'll take a look at is KGDB. This tool is used specifically for the debugging of Linux kernel, and is useful only if development on the Linux kernel source code is done inside the Eclipse IDE. To use this tool, a number of necessary configuration setups are required:
- Disable the C/C++ indexing:
- Select the C/C++ Indexer option from the Window | Preferences menu
- Unselect the Enable indexer checkbox
- Create a project where the kernel source code can be imported:
- Select the C/C++ | C Project option from the File | New menu
- Select the Makefile project | Empty project option and give a proper name to the project
- Unselect the Use default location option
- Click on the Browse button and identify the kernel source code local git repository location
- Press the Finish button and the project should be created
After the prerequisites are fulfilled, the actual configuration can start:
- Select the Debug Configuration option from the Run menu.
- Double-click on the GDB Hardware Debugging option to create a default configuration named <project name> Default.
- From the Main tab, browse to the location of the
vmlinux
built image, select the Disable auto build radio button, as well as the GDB (DFS) Hardware Debugging Launcher option. - For the C/C++ Application option available in the Debugger tab, browse for the location of the GDB binary available inside the toolchain (if ADT installer script is available, its default location should be
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gdb
). Select Generic serial option from the JTAG Device menu. The Use remote target option is a requirement. - From the Startup tab, select the Load symbols option. Make sure that the Use Project binary option indicates the correct
vmlinux
image and that the Load image option is not selected. - Press the Apply button to make sure the previous configuration is enabled.
- Prepare the target for the serial communication debugging:
- Set the
echo ttyS0,115200
|/sys/module/kgdboc/parameters/kgdboc
option to make sure the appropriate device is used for debugging - Start KGDB on the
echo g
|/proc/sysrq-trigger
target - Close the terminal with the target but keep the serial connectivity
- Set the
- Select the Debug Configuration option from the Run menu
- Select the previously created configuration and click on the Debug button
The bitbake commander offers the possibility of editing recipes and creating a metadata project in a manner similar to the one available in the command line. The difference between the two is that the Eclipse IDE is used to do the metadata interaction.
To make sure that a user is able to do these sort of actions, a number of steps are required:
- Select the Project option from the File | New menu
- Select the Yocto Project BitBake Commander wizard from the opened window
- Select the New Yocto Project option and a new window will be opened tp define properties of the new project
- Using Project Location, identify the parent of the
poky
directory - Use the Project Name option to define the project name. Its default value is poky
- For the Remote service provider variable, select the Local choice and make use of the same choice for the Connection name drop-down list
- Make sure that the Clone checkbox is not selected for an installed
poky
source directory
By using the Eclipse IDE, its features are available to be used. One of the most useful features is the quick search option that could prove to be very useful for some developers. Other benefits include the possibility of creating recipes using templates, editing them with syntax highlighting, auto completion, error reports on the fly, and many more.
of developed applications. These tools are used for enhancing various properties of the application and, in general, the development process and experience. The tools that will be presented are LTTng, Perf, LatencyTop, PerfTop, SystemTap, and KGDB.
- Start the tracing perspective by selecting Open Perspective from the Window menu.
- Create a new tracing project by selecting Project from the File | New menu.
- Select Control View from the Window | Show view | Other… | Lttng menu. This will enable you to access all these desired operations:
- Creating a new connection
- Creating a session
- Starting/stopping tracing
- Enabling events
Next, we'll introduce the user space performance analyzing tool called Perf. It offers statistical profiling of the application code and a simple CPU for multiple threads and kernel. To do this, it uses a number of performance counters, dynamic probes, or trace points. To use the Eclipse Plug-in, a remote connection to the target is required. It can be done by the Perf wizard or by using the Remote System Explorer | Connection option from the File | New | Other menu. After the remote connection is set up, interaction with the tool is the same as in the case of the command line support available for the tool.
LatencyTop
is an application that is used to identify the latencies available within the kernel and also their root cause. This tool is not available for ARM kernels that have Symmetric multiprocessing (SMP) support enabled due to the limitation of the ARM kernels. This application also requires a remote connection. After the remote connection is set up, the interaction is the same as in the case of the command line support available for the tool. This application is run from the Eclipse Plug-in using sudo
.
PowerTop is used to measure the consumption of electrical power. It analyzes the applications, kernel options, and device drivers that run on a Linux system and estimates their power consumption. It is very useful to identify components that use the most amount of power. This application requires a remote connection. After the remote connection is set up, the interaction with the application is the same as for the command line available support for the tool. This application is run from the Eclipse Plug-in using the –d option to display the output in the Eclipse window.
SystemTap
is a tool that enables the use of scripts to get results from a running Linux. SystemTap provides free software (GPL) infrastructure to simplify the gathering of information about the running Linux system via the tracing of all kernel calls. It's very similar to dtrace from Solaris, but it is still not suited for production systems, unlike dtrace. It uses a language similar to awk
and its scripts have the .stp
extension. The monitored data can be extracted and various filters and complex processing can be done on them. The Eclipse Plug-in uses the crosstap
script to translate the .stp
scripts to a C language to create a Makefile
, run a C compiler to create a kernel module for the target architecture that is inserted into the target kernel, and later, collect the tracing data from the kernel. To start the SystemTap plug-in in Eclipse, there are a number of steps to be followed:
- Select the systemtap option from the Yocto Project Tools menu.
- In the opened windows, the crosstap argument needs to be passed:
- Set the Metadata Location variable to the corresponding
poky
directory - Set Remote User ID by entering the root (the default option) because it has
ssh
access to the target-any other user that has the same privileges is also a good choice - Set in the Remote Host variable to the corresponding IP address for the target
- Use the Systemtap Scripts variable for the full path to the
.stp
scripts - Set additional cross options using the Systemtap Args field
- Set the Metadata Location variable to the corresponding
The output of the .stp
script should be available in the console view from Eclipse.
The last tool we'll take a look at is KGDB. This tool is used specifically for the debugging of Linux kernel, and is useful only if development on the Linux kernel source code is done inside the Eclipse IDE. To use this tool, a number of necessary configuration setups are required:
- Disable the C/C++ indexing:
- Select the C/C++ Indexer option from the Window | Preferences menu
- Unselect the Enable indexer checkbox
- Create a project where the kernel source code can be imported:
- Select the C/C++ | C Project option from the File | New menu
- Select the Makefile project | Empty project option and give a proper name to the project
- Unselect the Use default location option
- Click on the Browse button and identify the kernel source code local git repository location
- Press the Finish button and the project should be created
After the prerequisites are fulfilled, the actual configuration can start:
- Select the Debug Configuration option from the Run menu.
- Double-click on the GDB Hardware Debugging option to create a default configuration named <project name> Default.
- From the Main tab, browse to the location of the
vmlinux
built image, select the Disable auto build radio button, as well as the GDB (DFS) Hardware Debugging Launcher option. - For the C/C++ Application option available in the Debugger tab, browse for the location of the GDB binary available inside the toolchain (if ADT installer script is available, its default location should be
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gdb
). Select Generic serial option from the JTAG Device menu. The Use remote target option is a requirement. - From the Startup tab, select the Load symbols option. Make sure that the Use Project binary option indicates the correct
vmlinux
image and that the Load image option is not selected. - Press the Apply button to make sure the previous configuration is enabled.
- Prepare the target for the serial communication debugging:
- Set the
echo ttyS0,115200
|/sys/module/kgdboc/parameters/kgdboc
option to make sure the appropriate device is used for debugging - Start KGDB on the
echo g
|/proc/sysrq-trigger
target - Close the terminal with the target but keep the serial connectivity
- Set the
- Select the Debug Configuration option from the Run menu
- Select the previously created configuration and click on the Debug button
The bitbake commander offers the possibility of editing recipes and creating a metadata project in a manner similar to the one available in the command line. The difference between the two is that the Eclipse IDE is used to do the metadata interaction.
To make sure that a user is able to do these sort of actions, a number of steps are required:
- Select the Project option from the File | New menu
- Select the Yocto Project BitBake Commander wizard from the opened window
- Select the New Yocto Project option and a new window will be opened tp define properties of the new project
- Using Project Location, identify the parent of the
poky
directory - Use the Project Name option to define the project name. Its default value is poky
- For the Remote service provider variable, select the Local choice and make use of the same choice for the Connection name drop-down list
- Make sure that the Clone checkbox is not selected for an installed
poky
source directory
By using the Eclipse IDE, its features are available to be used. One of the most useful features is the quick search option that could prove to be very useful for some developers. Other benefits include the possibility of creating recipes using templates, editing them with syntax highlighting, auto completion, error reports on the fly, and many more.
bitbake commander offers the possibility of editing recipes and creating a metadata project in a manner similar to the one available in the command line. The difference between the two is that the Eclipse IDE is used to do the metadata interaction.
To make sure that a user is able to do these sort of actions, a number of steps are required:
- Select the Project option from the File | New menu
- Select the Yocto Project BitBake Commander wizard from the opened window
- Select the New Yocto Project option and a new window will be opened tp define properties of the new project
- Using Project Location, identify the parent of the
poky
directory - Use the Project Name option to define the project name. Its default value is poky
- For the Remote service provider variable, select the Local choice and make use of the same choice for the Connection name drop-down list
- Make sure that the Clone checkbox is not selected for an installed
poky
source directory
By using the Eclipse IDE, its features are available to be used. One of the most useful features is the quick search option that could prove to be very useful for some developers. Other benefits include the possibility of creating recipes using templates, editing them with syntax highlighting, auto completion, error reports on the fly, and many more.