Back

Home Our Services Programming Tools Business Unit Open Source Tools Porting the GNU Debugger for a RISC based processor

Porting the GNU Debugger for a RISC based processor

• Requirements
One of our Japanese customers required an instruction set simulator and debugger for a RISC processor to debug the programs and applications being developed for the target architecture. This debugger was also to be used in the testing of the tool chain (compiler, assembler, linker) being developed for the target architecture.

Therefore, we decided to port the GNU debugger to the new architecture, which would be able to support the different instruction sets, along with the various other features like exceptions, register set etc. for the new architecture.


• Challenges
• Understanding the GNU debugger and modifying it such that the existing system does not break, and at the same time ensuring that the functionality supported by the new architecture runs smoothly.
• Providing simulation and disassembly of some instructions which were exclusive to the new architecture.
• Support of exceptions, registers and other features not currently available in the GNU debugger.


• Solution
• Environment

OS	Linux
Language/Platform	C
Development model	Incremental development model
Quality validation tools	Numega Dev Partner Studio to check for memory errors and memory leaks QAC++ for static analysis of code

• Features
• Disassembly & Instruction Simulation for all the instructions
• Exceptions supported in the new architecture
• Breakpoints
• Debug commands
1. Single stepping
2. Reload
3. Restart
4. Go
5. Stop
6. Restart and Go
• Graphical user-interface
1. Disassembly window
2. Memory window
3. Register window
4. Output window
5. Script console window
6. Symbol window
7. Breakpoint window
8. Trace window
• Description

Since this was the first time we were undertaking GNU tool porting work, without having any prior knowledge of GNU systems, we needed to perform initial study and analysis. This was done by developing test programs and checking the execution flow in the GNU debugger.

The observed behavior was documented and the required changes were decided. Once we were clear about the work at hand, we divided the whole implementation so as to support the features in an incremental manner.

During the porting work, some features which were not present in the existing GNU debugger were added. These additions were commensurate with the existing code. They did not modify the behavior of the existing system, but at the same time ensured that the new features were supported for the target architecture. Any alterations which could not be supported (due to the inherent design constraints) were readily communicated to the customer and resolved.

After the addition of each new feature, may it be the support of a single instruction, or a new exception, or adding support for the register set, extensive testing was carried out; both on the target architecture as well as on the previously supported architectures, to ensure build/execution does not break.

The project had three phases in which features were added to the simulator/debugger incrementally. All the deliveries were completed in the planned schedule and the product was delivered in time and to the satisfaction of the customer.

Back