new gdb remote packet type

[Andrew Cagney]

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

There are two, equally correct, ways to view the registers being fetched:

- as array of values indexed by register number
- as flat byte addressable region with implied format

The current G packet format uses the latter, badly.  The implied format 
is determined somewhat arbitrarially by GDB-internals.  The qPart I'm 
suggesting, while still viewing registers as a flat sequence of bytes, 
is at least citing /proc and regsets for that bytes format (and a 
standard GDB is expected to understand anyway).

One way to think of qPart is that it provides a mechanism for accessing 
a number of separate address spaces - memory, gregset, auxv, etc.  For 
each, it always specifies an offset/length and gets back at least part 
of that request.  Passing a register index, doesn't fit into that model.

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

It's still large enough to hurt - people are still debugging across very 
  low bandwidth links.

Anyway, it sounds like you might (dig dig) be more interested  in the 
attached patch+hack (fernando nasser gets credit for the patch, I deny 
responsibility for the hack bit :-).  It adds a P packet for fetching 
individual registers which is something the existing remote protocol 
spec doco hints at.

Andrew


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diffs
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20040505/325dd964/attachment.ksh>