Improve GDB Simualtors

Mentors: Chris Johns, Joel Sherrill

Students: Past, Present, and Potential Students

Status: Uninitiated.

Introduction: This is a medium sized GSoC project with a medium skill level. The work requires figuring out the sim/common interfaces by code inspection and looking at other examples of it use. The first phase is to move the SIS to this framework and clean up various internal parts to use the sim/common interfaces. For example the SIS inferior interface is direct to gdb/remote-sim.c and sim/common has an inferior also to gdb/remote-sim.c which the SIS should sit under. Without this the run command is broken. We have hacked around this for gdb-7.11 by adding back the removed gdb code (run.c). This is not a sustainable solution. All the current SIS inferior calls, eg sim_open, sim_close, sim_read etc, need to be moved over. This requires the SIS's internal view of memory needs to match the sim/common's view so the SIS view and the GDB vewi, which is the user's view, are the same. There are a number of other issues such as printf which was hacked in a recent gdb-7.11 patch. All printf type output needs to be directed to the gdb filtered prints so MI is supported which we use in the rtems-test command. After glueing the SIS to sim/common further work can be done to implement hardware breakpoints. There is code in sim/common about this. The gdb-7.9 patch set from Jiri Gaisler contains an implementation for the SIS but it touches all the other sims. This patch was rejected upstream. The task is to merge the SIS support with the sim/common support. Finally tracing improvements in the simulator would be nice. All this needs to be sent to gdb patches with suitable FSF paper work.

After this there are other simulators to look at, specifically the aarch64 one and RTEMS. Having the aarch64 run an RTEMS app would be we nice. It only needs to do as far and a few instructions or maybe a 32bit build of RTEMS which the aarch64 should support.

There are also a number of Windows related issues in the simulators that would be nice to clean up.

Goal: Concise statement of the overall goal of the project. Refine this initial statement to include: project deliverables (code, docs, testing), required/suggested methodology, standards of quality, possible goal extensions beyond the main objective.

Requirements: List the requirements and level of expertise you estimate are required by the developer tackling this project will have to have: Required level of programming language(s), specific areas of RTEMS or tools, level of familiarity with RTEMS, cross-development, GNU/Linux, etx., development/documentation/testing tools, mathematical/algorithmic background, other desirable skills.

Resources: Current RTEMS developers, papers, etc that may help you in this project.

Acknowledgements

• who helped and did work

Miscellaneous Sections

As the project progresses, you will need to add build instructions, etc and this page will evolve from a project description into a HOWTO.

References

• TBD

Other sections: If you have more to say about the project that doesn't fit in the proposed sections of this template, feel free to add other sections at will.