Building Arm cross-compilation and online debugging environment with Eclipse and GDB

We build our development environment on Linux hosts, using Ubuntu 10.04 LTS as an example. Build the application development environment Install JRE

Eclipse relies on the Java environment, so you must first install the JRE or JDK. installing Eclipse and CDT

Download the latest Eclipse IDE to the Eclipse website.

We typically select the C + + version (the Eclipse IDE for C + + developers), which has its own CDT and does not have to install the CDT plugin separately. Choose Linux version when downloading, such as: eclipse-cpp-juno-linux-gtk.tar.gz

Simply extract the downloaded compressed package (eclipse-cpp-juno-linux-gtk.tar.gz) into a directory and run the executable eclipse.

After you run eclipse, you can first perform the configuration of the Eclipse Usage environment workspace. Create a cross application project

In the Eclipse main interface, click menu File > New > C + + project, and in the pop-up C + + Project dialog box, enter the project name. Select a project type (such as Executable/empty project) and be sure to select Cross GCC in Toolchains, which is the CDT's support for the crossover environment, providing additional functionality to facilitate the development of embedded applications.

Click Next to the "Select Configurations" page, and we take the default, direct next step, to the "Cross GCC Command" setting. Here we can fill in the Cross compilation tool chain of the prefix and path, such as:

Cross compiler prefix:arm-arago-linux-gnueabi-
Cross compiler path:/data/linux/ti-sdk5/linux-devkit/bin

The example above is the cross compilation package provided by the ARM chip vendor that we have installed. In general, the chipmaker provides such a cross compilation environment, including the target platform's compilation tool chain, GLIBC Library, binary tools, and other common tools. The above example is provided by TI for the DM3730 Development Package installation path and the program prefix (the REAL program is: ARM-ARAGO-LINUX-GNUEABI-GCC, ARM-ARAGO-LINUX-GNUEABI-LD, etc.)

Finally click Finish and a crossover item is created. For a set of cross compilation prefixes and paths, you can change the project's properties after it is created.

Here we write a simple test program, such as:

#include <iostream>
using namespace std;

int main (int argc, char * * argv)
{
    signal (0, 0);
    cout<< "This are a message from hellodm3730!\n";
    return 0;
}

Click Build and compile it. After compiling, we can see the compiled program in the binaries in the project directory on the left side of "project Explorer." Copy it to the target arm Development Board, run it, and the results are correct. Run Debugging

When the program is compiled into the binary code of the target platform, how to copy to the target board to run debugging is a problem.

We can download the compiled program to the target board via TFTP, that is, to install the TFTP server on the development host and use the TFTP command on the target board to fetch files to the host.

Another convenient approach is to deploy the NFS service on the development host, export a shared directory, and then use the Mount command on the target board to mount the shared directory on the development host locally. In this way, the development host and the target board use the same directory, there is no need to constantly download the program. NFS deployments can refer to the Use of NFS shared directories under Linux.

The ultimate solution is to build the GUI's online debugging environment, that is, after writing code, click Debug, Eclipse automatically compile the program, and then download the program to the target board, and then run open gdb online debugging, so you can step into debugging, like debugging a local program. Build online debugging environment Gdb+gdbserver General Introduction

The remote debugging environment consists of host GDB and the target debug stub, both through a serial port or a TCP connection. Use the GDB Standard serial protocol to work together to realize the monitoring and debugging function of the system kernel and upper layer application on the target machine. The debug stub is a piece of code in an embedded system that exists as a medium between the host GDB and the target debugger.

For now, embedded Linux system, there are three kinds of remote debugging methods, respectively, suitable for different occasions debugging work: normal list items with ROM monitor debug target machine program with KGDB Debug system kernel debug the user space program with Gdbserver

The difference of these three debugging methods mainly lies in the difference of the existence form of the remote debugging stub of the target machine, and the design idea and the realization method are basically the same.

And our most common use is to debug the application. is to use the Gdb+gdbserver way to debug. In many cases, users need to repeatedly debug an application, especially complex programs. Using the GdB method debugging, because of the limited resources of embedded system, it can not be debugged directly on the target system, which is usually debugged by Gdb+gdbserver. Source code Download

The GDB debugging environment of Embedded Linux consists of host and Target, and the host uses Gdbserver with Arm-linux-gdb,target board end. In this way, the application runs on the embedded target system, and GDB is debugging on the host side, so the remote debugging (Sqlremote) method is used. GDB debugging, the target system must include the Gdbserver program (on the host is on the hardware platform after the success of the download to the target machine), host must also install the GDB program. General Linux distributions have a running GDB, but developers can not directly use the release of GDB to do remote debugging, but to obtain GDB source code package for the arm platform for a simple configuration, recompile to the corresponding gdb. GDB's source code package can be downloaded from the GNU website. Configuring compilation and Installation

Again, the GDB remote Debugging suite, which includes the host-side gdb and target-side gdbserver, is not available for GDB, the PC version of GDB on the host, and it does not have target architecture (ARM)-related debugging support. So we should use GDB's source code, for the arm platform to compile a (toolchain or host) a special version. Of course, if the chip maker's cross compilation Suite already contains Arm-linux-gdb, we don't have to recompile gdb, just use it. In any case, the gdbserver still needs to be recompiled with the toolchain of the target board, because the crossover kit provided by the chip maker usually does not include gdbserver.

After downloading, unpack:

#cd/opt
#tar xzvf/tmp/gdb-6.8.tar.gz

Build configuration file, compile:

#cd/opt
#mkdir-P arm-gdb/build
#cd arm-gdb/build
#/opt/gdb-6.8/configure--target=arm-linux Opt/arm-gdb
#make
#make Install

In the above command, –target configures the GDB target platform, –PREFIXP specifies the location where the results of the compilation are stored, that is, the installation directory. After compiling, you can find the executable arm-linux-gdb, Arm-linux-gdbtui, Arm-linux-run in the/opt/arm-gdb/bin directory. Copy arm-linux-gdb to/usr/bin directory:

#cd/opt/arm-gdb/bin/
#cp arm-linux-gdb/usr/bin/

Below the gdbserver porting to the arm platform. The point is to specify the cross compilation chain (GCC and AR) for the target platform. We create a temporary compile directory to avoid fouling the original code.

#cd/home/kim
#mkdir gdb-build
#CC = "/DATA/LINUX/TI-SDK5/LINUX-DEVKIT/BIN/ARM-ARAGO-LINUX-GNUEABI-GCC" \
  ar=/data/linux/ti-sdk5/linux-devkit/bin/arm-arago-linux-gnueabi-ar \
  /opt/gdb-6.8/gdb/gdbserver/ Configure  --target=arm-linux--host=arm-linux
#make

In the above command, –target=arm-linux represents the target platform, –host indicates that the host side is running ARM-LINUX-GDB and does not need to configure-prefix because Gdbserver is not installed on the host side. Temporary environment Variables cc and AR are used to specify cross compilation and assembly options that will be applied when the configure of the same line of command executes.

If there's no error, build the Gdbserver executable in the/home/kim/gdb-build directory, and notice that you want to change its properties at this point, otherwise there may be an inaccessible situation, chmod 777 gdbserver change it to anyone can read and write to execute Use the Arm-linux-strip command to handle the Gdbserver, remove the extra symbolic information, make the elf file leaner, usually used at the end of the application, and then burn it to the/usr/bin of the root file system partition of the Flash (in this directory, The system can automatically locate the application, otherwise it must be run in the directory where the gdbserver resides, or it can be done via NFS mount. Just make sure Gdbserver can run on the Development Board.

After compiling the gdbserver, copy it to the/usr/bin directory on the target board, run it, and if you can display Help information, the cross compilation succeeds, such as:

#gdbserver
Usage:  gdbserver [OPTIONS] COMM PROG [ARGS ...]
        gdbserver [Options]--attach COMM PID
        gdbserver [options]--multi COMM COMM may

either is a TTY device (for serial debugging), or 
host:port to listen for a TCP connection.

Options:
  --debug               Enable general debugging output.
  --remote-debug        Enable Remote protocol debugging output.
  --version             Display version information and exit.
  --wrapper Wrapper-  Run wrapper to start new programs.
  --once                Exit After the connection has closed.

If you are prompted for other error messages, such as a binary file that cannot be executed, the compilation is unsuccessful. Note that the gdbserver we have crossed out cannot be run on the development host. command-line remote debugging

On the target board, run the gdbserver command to start debugging the test program and specify the IP and listener port number for the target board, such as:

#gdbserver 192.168.188.120:12345 HelloDm3730 (note, HelloDm3730 for the program to be debugged)
process HelloDm3730 created; PID = 625
Listening on port 12345

We see that the gdbserver has started properly and is waiting for the client program gdb to connect.

At this point we run ARM-LINUX-GDB on the development host, specify the IP and port of Gdbserver, and connect it, such as:

# arm-arago-linux-gnueabi-gdb 
(GDB) target remote 192.168.188.120:12345
remote debugging using 192.168.188.120:12345
0x400b57f0 in?? ()

Show "0x400b57f0 in??" () "indicates that you have connected to the remote Gdbserver and started debugging, at which point the target board terminal will display the remote debugging from host 192.168.188.201, and confirm the success of the debug connection again. The next debugging method is the same as for common native gdb.