This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: new gdb remote packet type
- From: Robert Picco <Robert dot Picco at hp dot com>
- To: Andrew Cagney <cagney at gnu dot org>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Tue, 04 May 2004 13:58:54 -0400
- Subject: Re: new gdb remote packet type
- References: <407F2BAB.4060408@hp.com> <40802711.3040104@gnu.org> <4087E8C0.30806@hp.com> <4087EE4B.4010805@gnu.org> <40912015.7070902@hp.com> <40928D64.8010209@gnu.org>
Andrew Cagney wrote:
Andrew Cagney wrote:
you'd prefer that I use the q-packet mechanism?
Yes, the qPart packet was designed for exactly the situtation you
encountered. It can specify a length/offset and return a short
transfer.
Andrew
Hi:
Does this represent what you are expecting of the qPart packet? I
saw no reason to export the type because this
packet is only useful in remote.c
While not immediatly, it is going to eventually be exposed out side of
remote.c, so we need to get what goes across the wire right up front.
To that end:
- use register sets
Unlike the G-packet, where the byte layout is determined by GDB
internal data structure, the byte layout needs to be specified by the
inferior's regsets. That in turn means specifying separate packets
for fetching all or part of each of "gregs", "fpregs", and "xpregs"(?).
- specify offset/length
I think your code is specifying a register number, it should view the
region as a sequence of bytes and fetch using offset/length. This
information can be obtained using "regset.h" (although that interface
might need some massaging).
- fetch lazy
Just request the region for the requested register. It's then up to
the remote end to determine that more/less of the region can be supplied.
Eventually this will also be added to the target vector, however, for
the moment something more local is definitly fine.
Andrew
Hi:
Well I must admit to being a little confused:) My intent is to not
introduce any architecture dependency in remote.c and just restructure
the g-packet to match what the target wants. I could be missing a point
here but the regset stuff looks very architecture dependent and it would
seem incorrect to use it in remote.c.
Well for offset I am using the regnum. We are inquirying whether the
target wants the reg mapped in the g-packet .
We could fetch lazy but this isn't currently done by remote.c because
most target g-packet payloads aren't very large. IA64 is the exception
with a payload in excess of 10,000 bytes.
I must be missing your larger objective here because my limited
knowledge of gdb is in remote.c.
thanks,
Bob