Using Eclipse

Developing Applications in Eclipse

Cross-Compiling from Eclipse Watch Enea's video about Cross-compiling and Remote Debugging of Applications. In order to use Eclipse to compile an application for a certain target architecture, you need to first install a cross-compilation toolchain cross-compilation toolchain toolchain cross-compilation (SDK SDK ), configure the cross-compiler in Eclipse, and then create a Yocto ADT Autotools project , which uses the Yocto SDK.INFO: This project type is still called ADT in Eclipse even though Yocto talks about standard and extentible SDK Installing the cross-compilation toolchain is pretty straightforward. All you have to do is to run the shell script provided with the release and follow the instructions, see Installing a Cross-Compilation Toolchain (SDK). Before creating the project, you must first configure the cross-compiler cross-compiler in Eclipse:Should images be added to the procedure below for ease of understanding? Select Window > Preferences > Yocto Project ADT to open a dialog.INFO: This project type is still called ADT in Eclipse even though Yocto talks about standard and extentible SDK Choose a Stand-alone pre-built toolchain. For the Toolchain Root Location option, specify the path to the cross-compilation toolchain, e.g. /opt/enea/<sdkversion>. For the Sysroot Location option, specify the path to the target sysroot directory inside the toolchain root location e.g. <extsdkdir>/tmp/sysroots/corei7-64-enea-linux/ If multiple architectures are supported by the SDK, select the desired target architecture from the drop-down list. You can save different profiles with different configurations. This makes it easy to compile the same code for different architectures by simply choosing the desired development profile. In Target Options, select the External HW option. More details on how to configure the cross-compiler can be found in the Yocto Project Software Development Kit (SDK) Developer's Guide 2.5. Change the Yocto version in the link if needed. There is also a good cheat sheet available in Eclipse, under Help > Cheat Sheets > Yocto Project > Creating a Hello World ANSI C or C++ Autotools Project. This cheat sheet covers all the steps up to building the project. Once you have configured the default options for the cross-compiler you can create a project: Follow the steps in the wizard to create the project: Select File > New > Project > C Project and click Next. Select Yocto Project ADT Autotools Project > Hello World ANSI C Autotools Project, and give the project a Project name before clicking Next. Having a hyphen character '-' in the name can cause configuration errors. Enter the Author and click Finish. This will automatically generate all the files needed, creating all necessary configurations for cross-compiling. For more on how to create a project, watch Enea's video about setting up an ADT project. Optionally, if you want to have specific options for cross-compiling this project, select Project > Change Yocto Project Settings and modify the options for this project only. Right-click on the project from the Project Explorer and choose Reconfigure Project. This will generate the necessary makefiles to build the project. Finally, build the project from Project > Build Project, or by right-clicking on the project in the Project Explorer and selecting Build Project. A binary file for the target architecture is created in the project directory. If you need to add more files or compiler flags or parameters to the Makefile, edit Makefile.am accordingly and then reconfigure the project. Eclipse displays the results from building a project in one Eclipse console, and reconfiguring a project in another one. Switching between the two consoles is necessary to view both outputs.

Debugging Applications from Eclipse Watch Enea's video about Cross-compiling and Remote Debugging of Applications. Using Eclipse you can build an application, deploy it on the target, and debug debug the source code remotely, all with a single mouse click. However, in order to achieve this you need to make certain configurations. When setting the cross-compiler options for a target, a run/debug configuration is created as a C/C++ Remote Application instance. The configuration is named according to this syntax <project>_gdb_-<suffix>, for example: hello_gdb_aarch64-enea-linux. If a run/debug configuration is not created when setting the cross-compiler options, perform the steps in Run/Debug Configuration Not Created. The instructions below describes how to use Eclipse to debug single-process applications on a target. For information on how to debug multi-process applications, see Debugging Multi-Process Applications from Eclipse. Use the run/debug configuration to connect the Eclipse GDB interface to the remote target, by doing the following: Should we add images for the procedure below as well? Select Run > Debug Configurations > C/C++ Remote application from the menu and choose the run/debug configuration from the instances under C/C++ Remote Application in the left pane. You can rename, duplicate or remove the configuration as needed. In the Main tab, do the following: Select an existing Connection from the drop-down list, or create a new one following the steps below: To create a new connection, click the New... button and select a connection type. For debugging applications an SSH connection is recommended. Choose a connection name and fill in the Host information section with the target's IP and the username. For Enea Linux, the default username is root and there is no password set. Depending on your network setup, select either Public key or Password-based authentication. If using Password-based authentication, leave the field empty when using the default root username. Click Finish. The new connection should now be available in the dropdown menu. This connection will be persist through all Run/Debug configurations. You can manage your saved connections in the Connections view from Window -> Show View -> Other... -> Connections. Select the binary C/C++ Application you want to deploy. If you click the Search Project button, Eclipse will parse the project and provide a list of all compiled binaries to choose from. Alternatively, you can Browse the file system for a binary, or use Variables to manually define the path. The Remote Absolute File Path is the path to which the binary on the target shall be deployed. Type it directly or click the Browse button and select a location on the remote target. Note that you need to specify the path including the filename. Optionally, you may choose not to download the application to the target, but instead debug an already downloaded application. You can also configure Eclipse to execute commands prior to launching the application, by specifying the commands in the corresponding field. In the Arguments tab you can specify various arguments to be passed to your application at launch-time. The Debugger tab deals with GDB specific configurations. This is automatically populated when configuring the cross-compiler. You may optionally choose additionally useful options as with any Eclipse GDB interface, e.g. whether to break at entering the main function or uploading shared libraries. To enable debugging with shared libraries, do the following: Retrieve the debug sources from the target, and store them in a dedicated folder on the local host. They are found in /usr/src/debug in the target rootfs. Set a path mapping your debug configuration. In the Source tab, click Add, select Path Mapping, and assign paths to the mapping: Compilation path: /usr/src/debug Local file system path (path to the debug sources retrieved from the target): <path_to_chosen_folder>/usr/src/debug In the Debugger/Shared Libraries tab, select option Load shared library symbols automatically and set the path to the shared library. The path depends on the processor architecture of your target. For 32-bit targets: <extsdkdir>/sysroots/<arch>-enea-linux/lib/.debug For 64-bit targets: <extsdkdir>/sysroots/<arch>-enea-linux/lib64/.debug Note that inside Eclipse you must load the shared libraries with debug information (not stripped). Shared libraries that get built into the rootfs of the target image have debug information stripped off, for size and speed optimizations. To debug applications that depend on shared libraries built outside the rootfs of the target image, the same procedure applies, with the exception that you must upload the required shared libraries to the target prior to starting the debugging session. If you upload them to /lib or /lib64 (depending on the target architecture) they get loaded by default. Otherwise, you must correctly update the LD_LIBRARY_PATH environment variable to match their look-up path. In Eclipse, you can automatically update this variable by setting the Commands to execute before application field to: export LD_LIBRARY_PATH=<path to uploaded shared libs> Once you have set up all the debug configurations, click Apply and Debug. This will launch the GDB on the target and open the Debug perspective. This is the standard Eclipse GDB interface when debugging a remote target. You can use all GDB features, such as setting breakpoints, stepping through code, reading variable values, reading registers, viewing memory, etc. When the debugger starts, Eclipse opens three consoles: The Remote Shell - used to launch the application and display its output. The GDB console - named as the path to its GDB binary. You can use this console to control the GDB from the command line. The third console is named as the path of the binary on the local machine, and is in fact an artifact that must be ignored. After having set up the debug configuration once, you can modify and rebuild your application and then relaunch it by simply clicking the Debug icon (the bug symbol) on the toolbar. You can also select the drop-down list for more configurations, and even add your configuration to the Favorites to easily retrieve it next time. If you only want to deploy and run the application, without debugging, you can use the same configuration as the one set up for debugging, but simply click the Run icon (the Play button symbol) from the toolbar menu, or select Run > Run Configurations and Run the chosen configuration.

Debugging Multi-Process Applications from Eclipse In Eclipse, remote debugging of an application that uses multiple processes multiple processes is slightly different compared to debugging a single process application as described in Debugging Applications from Eclipse. The following limitations exist for multi-process debugging: All debugged processes must share the same binary. Debugging only works in non-stop mode, i.e. stopping at a breakpoint only stops the current thread while other threads continue to execute. When using the GDB to debug multiple instances of the same process or thread, using the same symbols file, breakpoints will be common to all instances. That is, when setting a breakpoint in the code, all instances will stop there, and there is no way to filter them. The current thread filter in Eclipse is ineffective. Use the run/debug configuration to connect the Eclipse GDB client to the remote target: Go to Window > Preferences > Run/Debug > Launching > Default Launchers. Under C/C++ Attach to Applicaton > Debug select the checkbox GDB (DSF) Attach to Process via TCF/TE Launcher. Select Run > Debug Configurations... from the menu and choose the run/debug configuration from the instances under C/C++ Attach to Application in the left pane. You can create, rename, duplicate, or remove the configurations as needed. If you followed step 1, in the lower part of the dialog you will see that Using GDB (DSF) Attach to Process via TCF/TE Launcher is selected. If not, redo step 1 or click the Select Other... link, and use configuration specific settings by selecting the checkbox GDB (DSF) Attach to Process via TCF/TE Launcher. In the Main tab, do the following: Select the binary C/C++ Application you want to deploy. If you click the Search Project button, Eclipse will parse the project and provide a list of all compiled binaries to choose from. Alternatively, you can Browse the file system for a binary, or use Variables to manually define the path. Select an existing Connection from the drop-down list. If a connection is not available, create a new one following the steps in Setting up a TCF Connection from Eclipse. The Remote Absolute File Path is the path to the binary of the process you are planning to debug. Type it directly or click the Browse button and select a location on the remote target. You need an active TCF connection to the target for the Browse button to work (see chapter Setting up a TCF Connection from Eclipse). Note that you need to specify the path including the filename. Specify the PID of the remote process you are planning to attach. The Debugger tab deals with GDB specific configurations. Select the gdbserver in the Debugger dropdown. You may also choose other useful options as with any Eclipse GDB interface, e.g. whether to break at entering the main function or uploading shared libraries. The following actions are important: In the Main tab, enter the path to the GDB binary in the SDK. For example: <extsdkdir>/tmp/sysroots/x86_64-linux/usr/bin/<arch>-enea-linux/<arch>-enea-linux-gdb. Select option Non-stop mode. Once you have set up all the debug configurations, click Apply and Debug. This will launch the GDB and optionally open the Debug perspective for the process you selected. This is the standard Eclipse GDB interface when debugging a remote target. You can use all GDB features, such as setting breakpoints, stepping through code, reading variable values, reading registers, viewing memory, etc. Repeat these steps for each process you want to debug. You can have multiple debug sessions running simultaneously for multiple processes sharing the same source code.

Using the Postmortem Debugger When a program crashes post-mortem debugging core dump , it may leave a core dump which can be used to figure out exactly why the program crashed. Core dumps are disabled by default and have to be activated before debugging. After retrieving and transferring a core dump file to a host machine, Eclipse and the SDK tool generated for the target, can be used to analyze the application state at the time of the crash. If deep debugging within Linux libraries is needed, the debug SDK is required. See Installing Enea Linux SDK. To enable writing core dump files, two steps need to be performed on the target: allowing resources for core dumps and defining a core file name pattern. These settings are valid until the next reboot, unless made permanent by configuration changes in the root file system. Use the ulimit command to allow the system to use resources for core dumps. The ulimit command controls the resources available to a process started by the shell, on systems that allow such control. Type the following to use this command: ulimit -c unlimited To verify the result, type ulimit -a and see if the core file size is set to unlimited. User limits can also be changed from the application code using the function setrlimit(...) declared in the sys/resource.h header (see the manual available through man setrlimit). To make this permanent across a reboot, adjust the configuration in /etc/security/limits.conf. The next step is to specify the core pattern which defines the core dump file pattern name. The core pattern is defined in the /proc/sys/kernel/core_pattern. The format of a core pattern follows certain rules: The maximum length is 128 characters Default core dump name is core The string stored in core_pattern is used as a pattern template for the output filename. Certain string patterns (beginning with %) are substituted with their actual values. The patterns are: %<NUL> '%' is dropped %% output one '%' %p pid %P global pid (init PID namespace) %i tid %I global tid (init PID namespace) %u uid (in initial user namespace) %g gid (in initial user namespace) %d dump mode, matches PR_SET_DUMPABLE and /proc/sys/fs/suid_dumpable %s signal number %t UNIX time of dump %h hostname %e executable filename (may be shortened) %E executable path %<OTHER> both are dropped If the first character of the pattern is a '|', the kernel will treat the rest of the pattern as a command to run. The core dump will be written to the standard input of that program instead of to a file. By setting the value core_uses_pid to 1, the core dump filename gets the extension .PID, if the core_pattern does not contain "%p". For example, the default file name core becomes core.PID if the core_uses_pid is set, and no core_pattern is defined. Specify a core pattern by writing it to /proc/sys/kernel/core_pattern. For example: echo "<suitable_directory>/core.%e.%p.%h.%t" > /proc/sys/kernel/core_pattern To make the core dump file name permanent across a reboot, configure /etc/sysctl.conf. to reflect this choice, by adding a line like in the following example: kernel.core_pattern=<suitable_directory>/core.%e.%p.%h.%t. How to use the Eclipse post mortem debug configuration in order to view the call trace, for the core dump in the Eclipse GDB interface: Ensure a core dump can be created on the target, see the information above. To see the full call stack, the application object files, compiled with debug information, are needed (the -g option in gcc). After a core dump has been created, retrieve the core dump file from the target and store it on the host. In Eclipse on the host, you need the core dump file, the SDK for the target, the application executable, and access to the source code. Once you have those, do the following: Switch to the Debug perspective in Eclipse. Select Run -> Debug Configurations ... (scroll down if you don't see the option at first glance) -> C/C++ Postmortem Debugger. Make sure the C/C++ Application field refers to your project executable, and fill in the Core file field with the path to the downloaded core file. Under the Debugger tab, fill in the GDB Debugger field with the path to the GDB binary from the SDK. Example path: <extsdkdir>/tmp/sysroots/x86_64-linux/usr/bin/<arch>-enea-linux/<arch>-enea-linux-gdb Click the Debug button. Eclipse should switch into the Debug perspective (if it hasn't already) and the debugging instance should break somewhere inside the application. The call stack should be observable in the console and should show a termination message.

Debugging the Linux Kernel in Eclipse In this section you learn to set up Eclipse for KGDB KGDB kernel debugging over the serial port, with examples for the raspberrypi3 target. This is only given as an example, your Enea Linux distribution may contain other targets. The corresponding instruction for debugging outside Eclipse is available in Debugging the Linux Kernel (KGDB) from Command Line.LATER: Merge the two instructions to shrink the amount of text; most of it is the same. How to set up Eclipse for KGDB kernel debugging over a serial port: Make sure that the cross-compilation toolchain cross-compilation toolchain toolchain cross-compilation (SDK SDK ) is installed on the host, see Installing Enea Linux SDK. Ensure that the kernel debug image (vmlinux)is accessible on the host where you run Eclipse, and that you have permissions to execute it. You will later point to it in Eclipse. If you are using the default kernel delivered with Enea Linux, you can find it in the rootfs under the /boot folder. If you build your own kernel using bitbake, it should be available in your build folder. Located in, for example: tmp/work/raspberrypi3_64-enea-linux/linux-raspberrypi/1_4.9.59+gitAUTOINC+meta_machine-r0/image/boot/vmlinux-4.9.59 In Eclipse: Optional: The Linux kernel has a considerable amount of sources, and indexing the whole of it might take a lot of time. Save time by disabling C/C++ project indexing: Select Window > Preferences > C/C++ > Indexer. Unselect the Enable indexer checkbox. Create a project from the kernel tree: Select File > New > Project > C/C++ > C project. In the left panel, select Makefile project > Empty project, and give the project a name. Unselect the Use default location option. Click Browse and navigate to the location of the kernel sources (git folder). Click Finish. Create a C/C++ GDB Hardware Debugging configuration: Go to Run -> Debug Configurations. Double-click GDB Hardware Debugging. This will create a default configuration named project_name Default. In the Main tab: Browse to the location of the vmlinux image. As an alternative, you may select a different project to debug, but if you followed the steps above you should not need to modify this. Select the Disable auto build radio button. At the bottom of the window, make sure GDB (DSF) Hardware Debugging Launcher is selected. In the Debugger tab for C/C++ Application: Browse to the location of the GDB binary installed by the cross-compilation toolchain installer, by default: <extsdkdir>/tmp/sysroots/x86_64-linux/usr/bin/<arch>-enea-linux/<arch>-enea-linux-gdb. Select option Use remote target. In the JTAG Device, select Generic Serial from the dropdown list. In the GDB Connection String field, type the host's tty device used for the serial connection to the target, e.g. /dev/ttyUSB0. In the Startup tab: Deselect the Load image option. Select the Load symbols option. Ensure that the Use project binary option defaults to your vmlinux image. Click Apply to store the configurations above. Prepare the target for KGDB debugging: Configure a serial communication on the target, using the appropriate device for the target (e.g. ttyS0 for p2020rdb, ttyS2 for pandaboard, ttyPS0 for zynq): echo ttyS0,115200 > /sys/module/kgdboc/parameters/kgdboc Start KGDB on the target SysRq: echo g > /proc/sysrq-trigger Keep the serial connection open, but close the terminal to the target. Launch the debug session in Eclipse: Select Run > Debug Configurations. Select the configuration created above. Click the Debug button. The target halts in function kgdb_breakpoint(). The GDB view opens in Eclipse, and from here you can debug the kernel by giving ordinary GDB commands (resume, step, set breakpoint, etc.).