> On Oct. 18, 2015, 5:50 a.m., Nilay Vaish wrote:
> > src/arch/power/remote_gdb.hh, lines 56-61
> > <http://reviews.gem5.org/r/3155/diff/1/?file=50317#file50317line56>
> >
> >     How did you come up with these index values?

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


- Boris


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3155/#review7388
-----------------------------------------------------------


On Oct. 15, 2015, 5:59 a.m., Boris Shingarov wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3155/
> -----------------------------------------------------------
> 
> (Updated Oct. 15, 2015, 5:59 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> -------
> 
> Changeset 11174:42e0d672bd50
> ---------------------------
> power: Implement Remote GDB
> 
> 
> Diffs
> -----
> 
>   src/arch/power/SConscript 3a4d1b5cd05c 
>   src/arch/power/remote_gdb.hh 3a4d1b5cd05c 
>   src/arch/power/remote_gdb.cc PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3155/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Boris Shingarov
> 
>

_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to