GNU toolchain and Eclipse based development environment for 32-Bit-RISC/DSP microprocessor

Mario Rotim, Mladen Faraguna

SYSTEMCOM d.o.o.
Maksimirska 120, Zagreb, Croatia Telephone: +385 1 2339-592 Fax: +385 1 2339-590 E-mail: mario.rotim@systemcom.hr, mladen.faraguna@systemcom.hr

Summary Driven by strong technical and market needs today, embedded systems require high demanding development tools with shorter development cycle time and with benefits of Open Source Initiative as well. This paper presents development experience of system consisting of Open Source GNU toolchain and Eclipse environment for a 32-Bit-RISC/DSP microprocessor architecture. The GNU toolchain has been done on the basis of GCC 4.0.2 compiler, Binutils 2.16 and GDB 6.4 debugger. The Eclipse environment has been done on the basis of Eclipse 3.x. CDT 3.1.x plugin suitable for C/C++ application development and application debugging. The Eclipse environment is additionally enhanced with Bootp, NFS and Telnet/terminal protocols to support user friendly development board integration and application development. The system supports debug of standalone applications and debug applications under the uClinux 2.4 operating system.

input file

GCC

output file uClibc

cpp

cc1 g++

ld as elf2flt

gdb gdbserver

Fig. 1. GNU toolchain

II. GNU TOOLCHAIN

[1] Generally the GNU toolchain consists of GNU Compiler Collection (GCC), GNU Binutils (assembler, linker, and other tools) and GNU debugger. It is possible to extend this definition to cover even more components needed for additional toolchain functionality e.g. elf2flt, uClibc. All those particular tools of toolchain have general purpose component which is target independent and component which directly describes particular target system. The second component which is target dependant definitely involves some kind of overhead built in the system which decreases both functionality and processing performance. Functionality - because it is not possible to build optimal and flexible system which will perfectly presume all possible targets. Processing performance because a toolchain has to play with target definition even during the run time. Compilers as well as other components of a toolchain are very complex system, and in comparison with reduced development cycle time needed to finish GNU toolchain adoption for a specific target system those limitations are acceptable. 1) GNU Compiler Collection (in the following text GCC): GCC is generally set of compilers for different programming languages as C, C++, Fortran, Pascal, Objective C, Java and Ada or etc. Mostly, all those programming languages are derived from the same hardware description. There are minority of language specific issues which have to be defined for all of those specific languages. It is even possible to implement the new language in the GNU GCC

I. INTRODUCTION
Hardware systems always assume software systems designed precisely for such specific hardware systems. One of the common accepted ways how to create software for a specific hardware system is to use other dedicated software systems. There are different types of such dedicated software systems. Certainly wide accepted option today is to use Open Source GNU based toolchain (Fig. 1). The word toolchain represents set of tools used in a chain to produce executable object code (or other outputs) for a specific hardware system (in the following text target system). As an Open Source project the GNU toolchain supports number of different target systems, but the main idea of the GNU toolchain is to empower toolchain developers to as easily as possible adopt existing general toolchain functionality for a specific target system. This paper presents development experience of such GNU toolchain system for a 32-bit-RISC/DSP Microprocessor. Efficient toolchain is the only one key component of Integrated Development Environment (IDE) usually not even directly seen for an average user. There is a strong need to have IDE in form of GUI which will maximizes user productivity. The leading IDE software platform today is the Eclipse framework. Eclipse fully supports GNU toolchain integration with all GUI functionality, great flexibility and configurability. This paper also presents the development experience of Eclipse adoption and Eclipse plug-in design.

but it is not covered by this paper. Our work is focused on C and C++ languages only. GCC is the most complex tool in the toolchain. It consists of two parts. The front-end part lexes and parses the input file written in the C or C++ programming language and convert it to three intermediate languages to represent the program during compilation: GENERIC, GIMPLE and RTL representations. GENERIC and GIMPLE are target independent representation generated by front-end. RTL is target dependent representation and most of the work of the compiler is related to this representation. GIMPLE and RTL representations are used for the optimization passes. The GIMPLE optimization consists of all target independent optimizations. The back-end part of the GCC consists of RTL optimization which is target dependent and target code generation which is the last compiler phase. All target definitions and target specific functions, macros, etc. are located in the three basic files: - machine.md : machine description - machine.h : target description macros - machine.c : user-defined functions used in machine.md and machine.h Machine description file contains a pattern for each CPU instruction that the target microprocessor supports, functional unit definitions, latencies, assembler mnemonics, etc. 2) GNU Binutils: ld linker and as assembler are main tools among more than ten tools in the GNU Binutils collection of tools. The main work in preparing the GNU Binutils for the target system is done in Binary File Description Library (BFD or libbfd) [2]. The BFD represents the interface to the object file format for all Binutils tools and can be used in custom application as well. The BFD consists of the front-end and the back-ends. There is one back-end for every specific target system. The as assembler transforms assembler source code line by line into object code. This transformation is relatively straight forward and most work on as assembler that is target dependant is done in the files: tc-machine.c and tc-machine.h. ld linker is completely based on BFD. User can specify default linker script file which will use by default but linker script file can be changed during runtime. 3) GNU Project Debugger (GDB):The GDB is a great interface which allows user to control execution and behavior of target application on the hardware. The developed GDB for our target system allows different debugging scenarios. It supports so called stand alone application debugging using serial line connection when application runs on hardware

without any operating system. It is even possible to attach to already running process on the target hardware. The GDB also supports application debugging under the uClinux over the Ethernet network connection. User starts GDB server manually on the target hardware and communication established between GDB server and GDB on the user side. The GDB uses the BFD library of the target system and operating code from the GNU Binutils. Most important work on target specific functions in GDB is located in the remote serial procedures for communication with the target hardware and GDB server for the target hardware. 4) uClibc, elf2flt and uClinux 2.4: uClinux pronounced "you-see-linux", the name uClinux comes from combining the greek letter "" and the english capital "C". " " stands for "micro", and the "C" is for "controller". uClinux is a port of Linux to systems without a Memory Management Unit (MMU) and usually used for embedded systems. The same background is used for the uClibc too. The uClibc is a port of C library (glibc) for developing embedded Linux systems. Our project targeted uClinux 2.4 operating system and this is the main reason to integrate uClibc library and elf2flt into toolchain. The efl2flt tool is required by the uClinux to transform executable object code into so called FLAT format which can be loaded and executed under the uClinux. The elf2flt acts as a wrapper which manages calls to the ld linker and elf2flt converter tool as well.

III. ECLIPSE IDE

Eclipse is an open-source software framework written primarily in Java. It is primary designed for building IDE, but it can also be used for arbitrary tools. Eclipse began as an IBM Canada project. It was developed by Object Technology International (OTI) as a replacement for VisualAge, which itself had been developed by OTI [5]. In November 2001, Borland, IBM, MERANT and other companies formed a consortium to further the development of Eclipse as open source. In 2003, the Eclipse Foundation was created and reorganized as a non-profit organization a year later. The latest Eclipse version is 3.3.1.1 released on October 23, 2007. According to Eclipse Platform Whitepapers [3], the goal of the Eclipse Platform is:

Support the construction of a variety of tools for application development. Support an unrestricted set of tool providers, including independent software vendors (ISVs). Support tools to manipulate arbitrary content types (e.g., HTML, Java, C, JSP, EJB, XML, and GIF). Facilitate seamless integration of tools within and across different content types and tool providers. Support both GUI and non-GUI-based application development environments. Run on a wide range of operating systems, including Windows, LinuxTM, Mac OS X, Solaris, AIX, and HP-UX. Capitalize on the popularity of the Java programming language for writing tools.

Workbench uses JFace and SWT and provides UI personality of the Eclipse Platform and is based on views, editors and perspectives.

One of the major parts of Eclipse is the Rich Client Platform (RCP). RCP is a subset of Eclipse Platform. The following components constitute the rich client platform: OSGi - a standard bundling framework (handles bundlers that are key component of plugins). The Standard Widget Toolkit (SWT) which is a thin layer OS independent API tightly integrated with underlying native window system. JFace - A UI toolkit designed to work with SWT and bringing model view controller programming to SWT, file buffers, text handling, text editors.

With the exception of a small run-time kernel, everything in Eclipse is a plug-in [4]. A plug-in is the smallest unit of Eclipse Platform function that can be developed and delivered separately . Each plug-in defines its manifest which is handled by OSGi framework. Eclipse employs plug-ins in order to provide all of its functionality on top of (and including) the rich client platform, in contrast to some other applications where functionality is typically hard coded. This is the key concept we need to understand and is a tremendous strength of the Eclipse Platform. Each plug-in can define extension point which other plug-in can use. We can see the Eclipse Platform as an integration point of various plug-ins. This means that a plug-in you develop integrates with Eclipse in exactly the same way as other plug-ins; in this respect, all features are created equal. Eclipse provides plug-ins for a wide variety of features, some of which are through third parties using both free and commercial models. One of these features used that was reused in this project is CDT. A. CDT The CDT (C/C++ Development Tools) Project is a project built on the Eclipse framework. Its goal is to provide a fully functional C and C++ Integrated Development Environment (IDE) for the Eclipse platform. The major parts of the CDT are: [6] C/C++ Editor (basic functionality, syntax highlighting, code completion etc.) C/C++ Debugger (APIs & Default implementation, using GDB) C/C++ Launcher (APIs & Default implementation, launches and external application) Parser Search Engine Content Assist Provider Makefile generator

B. What we need The goal of this project was to provide IDE for 32-BitRISC/DSP which will support development of C/C++ applications. Eclipse framework together with CDT is a starting point for our solution. A lot of functionalities can be reused and some additional functionality is needed.
Fig. 2. Schematic view of the Eclipse Platform.

Our target processor can run two kinds of applications: standalone application and ucLinux application. Standalone applications are executed on the board alone

(without OS) and ucLinux application run on ucLinux OS which is running on the board. To provide support for the applications above we need to make our own launchers. New launchers are implemented as a new plug-in that uses extension points defined by the Eclipse Platform. In order to support uClinux application development, we need to implement some additional protocols enlisted below: Bootp, Tftp and NFS network protocols Kermit terminal used as a default uClinux console Telnet protocol All these services are also implemented as new plugins. Each plugin defines a new Eclipse View (a basic part of Workbench) which uses JFace and SWT controls. These features above are branded as a new application. This means that all the features above (Eclipse Platform, CDT our newly added functionality) were put together in a product that was delivered to the customer (Fig. 3.).

Our code

CDT

Eclipse Platform

Fig. 3. Schematic view of the final product .

IV. CONCLUSION
Theoretically speaking, Eclipse Platform and GNU toolchain gives us good starting point for rapid developing of custom IDE which will fully integrate and utilize the GNU based toolchain for the target microprocessor. A real life project shows that these expectations are met in practice and IDE development cycle time (man-month) reduced significantly. Default development platform for the IDE was the Linux. With small number of limitations and differences the IDE with all respective tools can be directly reused in the MS Windows/Cygwin environment and no additional work is needed. True flexibility is proved by the fact that network services Bootp, Tftp, NFS, Kermit, and Telnet are integrated as a nature Eclipse plug-in in the Eclipse based IDE. Future work will target integration of plug-ins for monitoring development board, running uClinux operating system, processes and resources. There are two achievements which represent step forward in current Eclipse based toolchains. First achievement is the integration of the Bootp, Tftp and finally NFS network file system directly and natively into Eclipse environment. This enables target hardware on the development board to boot and mount file system directly from the development system without any additional steps. The second achievement is the module for the GDB remote serial protocol. This module is also integrated natively into Eclipse environment and it manages communication between GDB and hardware without any operating system (stand alone debugging). The communication is optimized in the way it uses intelligent cashing mechanisms to increase speed and optimize interactions between Eclipse environment and target hardware.

Eclipse Platform Technical Overview , page 3, April 2006 [4] http://en.wikipedia.org/wiki/Eclipse_ %28software%29 Eclipse (software) [5] E. Clayberg, D. Rubel, Eclipse: Building Commercial-Quality Plug-ins, 2nd Edn., Addison Wesley Professional, xxxv, 2006 [6] What is the CDT?, http://wiki.eclipse.org/CDT/User/ FAQ#What_is_the_CDT.3F

ACKNOWLEDGMENT
The authors would like to acknowledge all colleagues in SYSTEMCOM d.o.o. who contributed to the project of GNU toolchain development in different project phases. The authors would like to thanks Mr. Boko Mrkovi, Mr. Zoran Stipaniev and Mr. Damir Vuk for all suggestions, ideas and supervising the project.

REFERENCES
[1] R. M. Stallman, GNU Compiler Collection Internals, GCC Developer Community, For GCC Version 4.2.0 [2] S. Chamberlain, libbfd The Binary File Descriptor Library, Cygnus Support , BFD 1.5 [3] http://www.eclipse.org/articles/WhitepaperPlatform-3.1/eclipse-platform-whitepaper.pdf,