power: Implement Remote GDB

Information
Submitter:	Boris Shingarov
Repository:	gem5
Branch:	default
Bugs:
Depends On:
Reviewers
Groups:	Default
People:

Description

Changeset 11175:6cd0d5e40222
---------------------------
power: Implement Remote GDB

Testing Done

src/arch/power/remote_gdb.hh (Diff revision 1)

How did you come up with these index values?

Boris Shingarov Oct. 18, 2015, 5:29 a.m. (Oct. 18, 2015, 5:29 a.m.)

Nilay,

Initially these values came from an RSP client which we use here to connect to a number of PPC targets.  Although I didn't have doubts about the values themselves being correct per se (the client has been working with them for quite a while), it's ultimately how GDB calculates these offsets which is the final proof.  In gdb/remote.c, the function process_g_packet() calls regcache_raw_supply() for each register, using struct packet_reg.regnum and packet_reg.offset to index into the register state store and the packet buffer, respectively.  Stepping through the last 'for' cycle in process_g_packet() confirms what the values are.  The question of how this array of packet_reg's is initialized, is a more intricate question, and historically this has evolved from simply hardcoded (which is still present in ppcobsd-tdep.c, see line 300 and below) to the versatile mechanism in ppc-linux-tdep.c which takes into account the possible variation in register sets on different PPC implementations (32-bit vs 64-bit, presence of Altivec or VSX extensions, etc; see gdb/ppc-linux-tdep.c).

As I mentioned in the comment in remote_gdb.cc:177-183, ideally I'd like to be able to accommodate this flexibility, but as a first step, enabling GEM5 to debug simulated code at all seems like a reasonable first goal.  Flexible register sets seem to me like a much larger undertaking, requiring first to overcome some difficulties arising from how GEM5 implements RSP.  For example, the G-packet size is calculated before the context knows enough about the workload -- e.g. we don't know at that stage whether we are running in 32- or 64-bit mode.  So the code sets "size" to be big enough for the biggest case.  Well, GDB objects (gdb/remote.c:6565 in GDB 7.10), and not only on POWER but also on SPARC and ARM.  Doing something about that, would be my next step, but it certainly isn't within the scope of this patch.

Boris