This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: G packet format ...


Based on the comments so far, and some trying this by hand, I'd like to 
suggest a few refinements:

	For the multi-line version, a line with a leading ``#'' is considered a 
comment and is discarded.

	For the multi-line version, a blank line is considered a comment and is 
discarded.  (Note this is different).

	The target can send less than G packet length bytes.  The missing bytes 
are assumed to be zero (and registers will be show with zero values). 
(This is, more than anything, to remind me to fix that bit of the remote 
protocol spec.)

	The target can send more than G packet length bytes.  The additional 
registers will have their GDB value updated.  However, not supplying 
those registers does not result in their value being set to zero.

As for where to chop the G packet, I'd like to propose ``---'' vis:

	4:r0
	8:r1
	4:r2
	4
	8:r3
	---
	4:spr0:1000
	4:spr1

Other idea's very welcome.

--

There is currently a multi-arch method REGISTER_BYTES_OK(nr bytes in 
packet) which returns true if ``nr bytes in packet'' matches certain 
values. Two targets use this:

	cris	rejects short packets
	m68k	only accepts a packet containing the GPRs or GPRs+FPRs rejecting short 
packets.

Any suggestions on how to incorporate that into the semantics (a ``===' 
separator?).  Or perhaps that check could simply be removed.

--

Another problem, down the track, eluded to by Frank is for targets with 
large numbers of registers.   Entering:  ``4:r0;4:r1.....4:r4000'' by 
hand could be tedious.  There will probably eventually be a need for a 
an expansion mechanism, something like: ``4:r{0-4000}''

Andrew

----


> Hello,
> 
> For those that don't know, GDB's remote protocol G packet currently determins the layout of GDB's internal register cache.  Doh!
> 
> As part of breaking^D^D^Dfixing this, I'd like to introduce a new CLI command that allows the user to specify the G packet (and in fact the entire remote protocol numbering) at runtime.
> 
> The commands are:
> 
>     set remote registers <spec>
> and show remote registers
> 
> (better names welcome).  The interesting thing is the spec:
> 
>     <spec> ::= <entry> { <sep> <entry> }* ;;
>     <entry> ::= <size> [ ":" <name> [ ":" <pnum> ] ] ;;
>     <sep> ::= ";" | "\n" ;;
> Where:
>     <name>    is the name of a raw register
>     <size>    is the byte size of a register
>     <pnum>    is the [Pp] register number
> 
> Eg:
>     8:r0
>     8:r1
>     4:r2
>     4
>     8:r3
> 
>     4:spr0:1000
>     4:spr1
> 
> or: 8:r0;8:r1;4:r2;4;8:r3;;4:spr0:1000;4:spr1
> 
> GDBserver might use the first form (\n) while GDB's CLI would use the second form.
> 
> For want of a better way to define the semantics, try the attached shell script.  What follows is an attempt at an english description:
> 
> The spec is divided into two parts separated by a blank entry. Additional blank entries, after the first, are ignored.
> 
> The first part describes registers that are transfered via either the [Gg] packets or the [Pp] packets. Each entry specifies a number of bytes in the [Gg] packet and then, optionally, the GDB internal name corresponding to those bytes.  Unnamed entries are written as zero.
> 
> The second part describes registers that are only transferable via the [Pp] packets.  Size entries in this part of the spec are ignored.
> 
> The [Pp] packet register number of the first register is zero (unless explicitly specified).  The [Pp] packet register number of succeeding registers, if not explicitly specified, is determined by adding one to the previous register's number.  (Yes ``1:r1:1000;;4:r0;0'', while stupid, is still legal.)
> 
> If GDB's internal register is smaller than the packet specification then high bits are discarded to fit.
> 
> If GDB's internal register is larger than the packet specification then we've got a problem.  A guess is zero extend unless a -ve size is specified which would imply sign extend.  Worry about this when it actually happens.
> 
> -- 
> 
> NB:  If you didn't catch on.  GDB currently doesn't implement the ``read single register'' packet yet this spec assumes this.
> 
> -- 
> 
> NB: Why do this?
> 
> The objective is to decouple the remote protocol's G packet from the rest of GDB.  That way, GDB has greater flexability in how it implements its regcache.  For instance, with the MIPS, it will be possible to have a single internal register layout while still being able to connect to all the remote MIPS targets.
> 
> -- 
> 
> comments, better suggestions, code?
> Andrew
> 
> 



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]