# GSoC '24 - Final Project Report

The following report summarises the work I have done during Google Summer of Code 2024, along with the results, scope for improvements and future work. This also serves as the final project report with all the contributions.

Note: The work done during the course of this Project (the code I have written), can be found here

# Background

My journey into Open Source began with a modest contribution — a documentation fix for a tool I was using. I encountered some build issues, realized that a few steps in the instructions were incorrect, and submitted a PR to correct them. It wasn’t until later that I fully grasped the impact of that contribution. Knowing that my small fix could help others avoid the same frustration gave me a sense of fulfillment.

I discovered RTEMS while exploring organizations participating in GSoC 2024. As I browsed through the list of projects, one in particular caught my eye — tagged with GDB and Python . Given my background in Reverse Engineering, I was immediately drawn to it and knew I wanted to make it my project. When I received my GSoC acceptance email on May 2nd, during my 2nd year in Undergrad College, I knew this summer was going to be something special. I had heard a lot about the mentor-mentee model that GSoC champions and was eager to experience it firsthand.

# About the Project

RTEMS (Real-Time Executive for Multiprocessor Systems) is an open-source real-time operating system (RTOS) designed for embedded systems requiring high reliability and deterministic behavior.

RTEMS provides the capability to build custom toolchains tailored to various target architectures, leveraging standard tools like GCC, Binutils, GDB and many more. These tools are essential for compiling, linking and debugging embedded applications on RTEMS.

The project involved modifying the GNU Debugger (GDB) to enhance its debugging capabilities within RTEMS.

# Problem Statement

GDB includes built-in support for automatically loading Python, but this feature is limited to dynamic executables. In such cases, when a specific library is loaded by the object file in GDB, the linker triggers GDB to load the corresponding pretty-printing scripts for that library.

However, RTEMS is fully statically linked, and this automatic loading does not apply to statically linked executables. Without a linker to notify GDB when a library is loaded, Python is not automatically loaded. As a result, many features that rely on Python are unavailable, leading to a significant loss in functionality during debugging.

# Project Goals

• Integrate a Python initializer into GDB for RTEMS to facilitate enhanced debugging.
• Enable GDB to automatically load pretty-printing scripts for RTEMS structures and libstdcxx classes.
• Seamlessly integrate these changes into the RTEMS toolchain, reducing the need for involvement from the user.

# Approach

A brief summary of my approach is as follows:

• Initial Exploration: I began by reviewing existing solutions employed by companies like Rust and AdaCore, which typically involve adding a wrapper over the host GDB to resolve paths for pretty-printers. To gain deeper insights, I engaged in discussions with developers from both companies as well as with GDB developers to understand the rationale behind this approach. However, I found this method unsuitable for RTEMS due to its use of a distinct toolchain for each build, separate from the host toolchain. Additionally, the wrapper approach proved to be generally inefficient for our needs.
• Implemented Solution: I introduced a .debug_gdb_scripts section to every ELF binary. This was done by adding the section in the cpukit/sapi/src/exinit.c file, since it is linked to every application built on RTEMS. As a result, every RTEMS-built application now includes this section.
• Python script execution: This new executable section contains a snippet of Python code that corrects paths and triggers GDB to run a script called pprinter.py . This script is responsible for registering both libstdcxx and RTEMS pretty-printers.
• Toolchain Integration: The stdcxx.py script, which registers the libstdcxx pretty-printers, needs to know the version of GCC being used since the pretty-printer scripts provided by GCC vary with versions. Therefore, the script is built alongside the toolchain to ensure compatibility.
• RTEMS Pretty-Printer Registration: Finally, the pprinter.py script invokes a build function from rtems_pprinter.py, which registers all the RTEMS-specific pretty-printers.

Here is a flow chart highlighting the work flow underwent for the entire project:

(Note: The boxes in Blue signify changes that apply to every application being built now on, and Yellow boxes signify changes to supporting scripts and updates to the build process)

# Work Completed

NOTE: These are the Merge Requests I made, all of which have gotten approved and merged to the upstream branch

# Python Initializer for GDB

• Merge Request !98 in RTOS: Implemented a custom section .debug_gdb_scripts in RTEMS executables for GDB to load Python scripts automatically.
• Developed and tested integration with the RTEMS build system to ensure Python scripts are executed upon loading an application.

# Pretty-Printers Integration

• MR !26 in Tools: Added support for pretty-printers for RTEMS-specific data structures.
• MR !26 in Tools: Created a script pprinter.py to enhance GDB's ability to display RTEMS structures in a user-friendly format.

# Integration with RTEMS Toolchain

• MR !35 in RSB and MR !48 in RSB: Modified the RTEMS Source Builder (RSB) to include the necessary changes for building stdcxx.py with the latest GCC.
• MR !43 in Docs: Updated documentation to reflect new features and usage instructions.

# Current State

• All major features have been implemented and tested.
• Python initialization and pretty-printer support have been integrated into the RTEMS build system.
• Pretty-printers for some basic RTEMS score structures have been written and tested.
• The Documentation has been updated with the changes made to GDB, and on setting up a debugging environment for embedded debugging.

# Communication and Work Management

• Discord was the primary platform of communication between my mentors and I, along with other members of the community.
• Weekly meetings to discuss Status Updates and keep everyone up to date with the project.
• The RTEMS Gitlab instance was used to coordinate issues, tickets, and Merge Request discussions, along with engineering discussions on Discord.

# Future Scope for the Project

• Add more RTEMS pretty-printer to support the feature for a larger number of Structures and Objects.
• Create a new class of RTEMS GDB commands (which would again, be automatically loaded and set up with no work from the User's perspective).
• Extending the RTEMS Documentation further to add Debugging manuals for different debuggers, and eventually add RTEMS-specific GDB commands.

# Challenges Faced and Things Learned

# Challenges:

# Integrating Python and GDB with Static Linking in RTEMS

• RTEMS uses static linking, which complicates GDB's ability to automatically load Python scripts, a feature that works for dynamically linked executables. This required developing a custom solution to ensure Python scripts could be executed within the RTEMS environment.

# Developing a Custom Solution for Script Loading

• The conventional methods for loading Python scripts in GDB did not apply to RTEMS. I had to devise a new method to introduce a .debug_gdb_scripts section in RTEMS executables.

# Things Learned:

# Adaptability and Problem-Solving

• I learned to adapt to unexpected challenges, such as implementing a novel solution for integrating Python into GDB for RTEMS. This required creativity and persistence, especially when initial approaches did not work.
• Developed a stronger ability to think outside the box and approach problems from different angles.

# Effective Communication

• Regular communication with mentors and team members was crucial. Coordinating through platforms like Discord and GitLab helped me understand the importance of clear, consistent updates and feedback.
• Enhanced skills in articulating ideas and progress effectively, which is vital for collaborative work.

# Time Management

• Balancing the demands of GSoC with other commitments required careful planning and prioritization. Managing a project with defined milestones and deadlines improved my time management skills.
• Improved ability to set realistic goals, manage deadlines, and handle multiple tasks efficiently.

# Project Ownership and Responsibility

• Taking ownership of the project from inception to completion underscored the importance of responsibility. Ensuring that my contributions were valuable and well-documented was a crucial aspect of this.

# Feedback and Iteration

• Receiving and acting on feedback was essential for refining my work. Iterative improvement based on input from my mentors helped me produce better results.

# Note of Thanks

This project would not have seen its successful completion without the ongoing support of many people. I would specially like to thank:

• Christian Mauderer and Chris Johns: For being fantastic mentors who were always ready to help me, and were patient with me (even with things I was initially clueless about). They have been with me from the very start and continue to support me.
• Joel Sherrill, Gedare Bloom and Amar Takhar: For being awesome maintainers and helping me along the way in more ways than I can recollect - not just regarding my project but also discussions outside it.
• My mentors and peers at team bi0s - specifically my mentor AmunRha - for inspiring me to try out GSoC and encouraging me throughout.
• My family, for their selfless support.

# Footnotes

• Project Selection link
• Proposal
• Project Tracker (Gitlab Epic)