G packet format ...

G packet format ...

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 2731 bytes --]

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

[-- Attachment #2: reg.sh --]
[-- Type: text/plain, Size: 430 bytes --]

#!/bin/sh

pnum=0
offset=0

IFS=:

printf "name\tsize\tpnum\toffset\n"

while read size name num
do
    if test x"${size}" = x; then
	echo "--- END -- OF -- G -- PACKET --"
	offset=
	continue
    fi
    if test x"${num}" = x; then
	num=${pnum}
    fi
    if test x"${name}" != x; then
	printf "${name}\t${size}\t${num}\t${offset}\n"
    fi
    pnum=`expr ${num} + 1`
    test "${offset}" && offset=`expr ${offset} + ${size}`
done

Re: G packet format ...

[Daniel Jacobowitz]

On Mon, Nov 12, 2001 at 12:24:04AM -0500, Andrew Cagney wrote:
> Hello,
> 
> For those that don't know, GDB's remote protocol G packet currently 
> determins the layout of GDB's internal register cache.  Doh!

Indeed.

> 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.

I guess I posted my gdbserver register cache patch before I converted
it to generate them from a shell script.  Here's what I've been using. 
I didn't consider the issue of only-transferable-in-P-packet registers
(and I still don't see a good reason... well, maybe I can come up with
one, actually.  Things that react when read.).

Here's an example and a shell script; ideally these would be built into
an archive and then linked to both gdb and gdbserver.  Possibly
autogenerate a manual chapter from them?  Should not be hard.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

/* *INDENT-OFF* */ /* THIS FILE IS GENERATED */

/* A register protocol for GDB, the GNU debugger.
   Copyright 2001 Free Software Foundation, Inc.

   This file is part of GDB.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software
   Foundation, Inc., 59 Temple Place - Suite 330,
   Boston, MA 02111-1307, USA.  */

/* This file was created with the aid of ``regdat.sh'' and ``dat/reg-i386.dat''.  */

struct reg regs_i386[] = {
  { "eax", 0, 4 },
  { "ecx", 4, 4 },
  { "edx", 8, 4 },
  { "ebx", 12, 4 },
  { "esp", 16, 4 },
  { "ebp", 20, 4 },
  { "esi", 24, 4 },
  { "edi", 28, 4 },
  { "eip", 32, 4 },
  { "eflags", 36, 4 },
  { "cs", 40, 4 },
  { "ss", 44, 4 },
  { "ds", 48, 4 },
  { "es", 52, 4 },
  { "fs", 56, 4 },
  { "gs", 60, 4 },
  { "st0", 64, 10 },
  { "st1", 74, 10 },
  { "st2", 84, 10 },
  { "st3", 94, 10 },
  { "st4", 104, 10 },
  { "st5", 114, 10 },
  { "st6", 124, 10 },
  { "st7", 134, 10 },
  { "fctrl", 144, 4 },
  { "fstat", 148, 4 },
  { "ftag", 152, 4 },
  { "fiseg", 156, 4 },
  { "fioff", 160, 4 },
  { "foseg", 164, 4 },
  { "fooff", 168, 4 },
  { "fop", 172, 4 },
  { "xmm0", 176, 16 },
  { "xmm1", 192, 16 },
  { "xmm2", 208, 16 },
  { "xmm3", 224, 16 },
  { "xmm4", 240, 16 },
  { "xmm5", 256, 16 },
  { "xmm6", 272, 16 },
  { "xmm7", 288, 16 },
  { "mxcsr", 304, 4 },
};

const char *resume_regs_i386 = { "ebp", "esp", "eip", 0 };

<snip here>


#!/bin/sh -u

# Register protocol definitions for GDB, the GNU debugger.
# Copyright 2001 Free Software Foundation, Inc.
#
# This file is part of GDB.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

move_if_change ()
{
    file=$1
    if test -r ${file} && cmp -s "${file}" new-"${file}"
    then
	echo "${file} unchanged." 1>&2
    else
	mv new-"${file}" "${file}"
	echo "${file} updated." 1>&2
    fi
}

# Format of the input files
read="type entry"

do_read ()
{
    type=""
    entry=""
    while read line
    do
	if test "${line}" = ""
	then
	    continue
	elif test "${line}" = "#" -a "${comment}" = ""
	then
	    continue
	elif expr "${line}" : "#" > /dev/null
	then
	    comment="${comment}
${line}"
	else

	    # The semantics of IFS varies between different SH's.  Some
	    # treat ``::' as three fields while some treat it as just too.
	    # Work around this by eliminating ``::'' ....
	    line="`echo "${line}" | sed -e 's/::/: :/g' -e 's/::/: :/g'`"

	    OFS="${IFS}" ; IFS="[:]"
	    eval read ${read} <<EOF
${line}
EOF
	    IFS="${OFS}"

	    # .... and then going back through each field and strip out those
	    # that ended up with just that space character.
	    for r in ${read}
	    do
		if eval test \"\${${r}}\" = \"\ \"
		then
		    eval ${r}=""
		fi
	    done

	    break
	fi
    done
    if [ -n "${type}" ]
    then
	true
    else
	false
    fi
}

if test ! -r $1; then
  echo "$0: Could not open $1." 1>&2
  exit 1
fi

copyright ()
{
cat <<EOF
/* *INDENT-OFF* */ /* THIS FILE IS GENERATED */

/* A register protocol for GDB, the GNU debugger.
   Copyright 2001 Free Software Foundation, Inc.

   This file is part of GDB.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software
   Foundation, Inc., 59 Temple Place - Suite 330,
   Boston, MA 02111-1307, USA.  */

/* This file was created with the aid of \`\`regdat.sh'' and \`\`$1''.  */

EOF
}


exec > new-$2
copyright
offset=0
i=0
name=x
resume=x
exec < $1
while do_read
do
  if test "${type}" = "name"; then
    name="${entry}"
    echo "struct reg regs_${name}[] = {"
    continue
  elif test "${type}" = "resume"; then
    resume="${entry}"
    continue
  elif test "${name}" = x; then
    echo "$0: $1 does not specify \`\`name''." 1>&2
    exit 1
  else
    echo "  { \"${entry}\", ${offset}, ${type} },"
    offset=`expr ${offset} + ${type}`
    i=`expr $i + 1`
  fi
done

echo "};"
echo
echo "const char *resume_regs_${name} = { \"`echo ${resume} | sed 's/,/", "/g'`\", 0 };"

# close things off
exec 1>&2
move_if_change $2

Re: G packet format ...

[Andrew Cagney]

>> 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.
> 
> 
> I guess I posted my gdbserver register cache patch before I converted
> it to generate them from a shell script.  Here's what I've been using. 
> I didn't consider the issue of only-transferable-in-P-packet registers
> (and I still don't see a good reason... well, maybe I can come up with
> one, actually.  Things that react when read.).

[x86 example deleted]

Doesn't the x86 have the potential for 4 billion MSRs? :-)

	Andrew

Re: G packet format ...

[Daniel Jacobowitz]

On Mon, Nov 12, 2001 at 12:57:31AM -0500, Andrew Cagney wrote:
> >>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.
> >
> >
> >I guess I posted my gdbserver register cache patch before I converted
> >it to generate them from a shell script.  Here's what I've been using. 
> >I didn't consider the issue of only-transferable-in-P-packet registers
> >(and I still don't see a good reason... well, maybe I can come up with
> >one, actually.  Things that react when read.).
> 
> [x86 example deleted]
> 
> Doesn't the x86 have the potential for 4 billion MSRs? :-)

I wouldn't know :)  It's my least-familiar platform; I only picked it
because the register data was short :P

I'm a little skeptical of using the P packet for registers
not-present-in-all-cases, either.  Perhaps in the morning I'll be able
to figure out why.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: G packet format ...

[Fernando Nasser]

Andrew 

What about having built-in sets of such configurations and 
letting the user select from the one available for the
currently selected architecture.

Like:

show remote registers

(prints the currently selected spec and the available ones)

set remote registers <spec>

where <spec> is from the list of available ones.

For instance, for i386, one could have:

i386-std
i386-extended
i386-cygmon
i386-codetap


This way we can minimize the risk of a mismatch with the target.


-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: G packet format ...

[Andrew Cagney]

> Andrew 
> 
> What about having built-in sets of such configurations and 
> letting the user select from the one available for the
> currently selected architecture.

Yes true.  Get something basic working first though :-)

Andrew

Re: G packet format ...

[Frank Ch. Eigler]

cagney wrote:

: [...]  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. [...]

I assume the intent is eventually (soon?) to query the remote target
for its own remote-register-spec string.  After all, it knows best.
If so, is it a possible problem that the specification string of a
large-register-bank machine may itself be so long as to exceed various
packet-size limits?

- FChE

Re: G packet format ...

[Andrew Cagney]

> cagney wrote:
> 
> : [...]  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. [...]
> 
> I assume the intent is eventually (soon?) to query the remote target
> for its own remote-register-spec string.  After all, it knows best.
> If so, is it a possible problem that the specification string of a
> large-register-bank machine may itself be so long as to exceed various
> packet-size limits?

That might happen (like querying a target for its architecture). 
However it is beyond the scope of this immediate change.

Andrew

Re: G packet format ...

[Andrew Cagney]

>> >I guess I posted my gdbserver register cache patch before I converted
>> >it to generate them from a shell script.  Here's what I've been using. 
>> >I didn't consider the issue of only-transferable-in-P-packet registers
>> >(and I still don't see a good reason... well, maybe I can come up with
>> >one, actually.  Things that react when read.).

[...]

> I'm a little skeptical of using the P packet for registers
> not-present-in-all-cases, either.  Perhaps in the morning I'll be able
> to figure out why.

Not sure it is relevant, however, the following feature of the remote 
protocol is interesting.

The G packet contains all registers.  There for, if the G packet is 
short, GDB assumes that any missing registers are zero.

Consider the sequence:

Target stops.  Supplies value for register 1000 in T packet.

User does something to cause register ``0'' to be fetched and this is 
done via a G packet.

Two things can happen:

	o	target supplies GDB with all registers (0..1000)
		which makes for a very large G packet.

	o	target supplies GDB with a subset of registers
		(a short packet) and GDB interprets that to mean
		that register 1000 should be set to zero.

Ulgh.


By allowing registers beyond the end of a G packet. These problems are 
avoided.

A variation on my change might be to allow the target to bundle up more 
than the official NR of registers in a G packet.  However, not having 
them does not mean that they are zero.

enjoy,
Andrew

Re: G packet format ...

[Andrew Cagney]

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
> 
>