Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <cagney@gnu.org>
To: Robert Picco <Robert.Picco@hp.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: new gdb remote packet type
Date: Fri, 30 Apr 2004 17:31:00 -0000	[thread overview]
Message-ID: <40928D64.8010209@gnu.org> (raw)
In-Reply-To: <40912015.7070902@hp.com>

> 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



  reply	other threads:[~2004-04-30 17:31 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-16  0:45 Robert Picco
2004-04-16 18:33 ` Andrew Cagney
2004-04-22 15:45   ` Robert Picco
2004-04-22 16:09     ` Andrew Cagney
2004-04-29 15:31       ` Robert Picco
2004-04-30 17:31         ` Andrew Cagney [this message]
2004-05-04 17:56           ` Robert Picco
2004-05-05 19:10             ` Andrew Cagney
2004-05-06 19:41               ` Robert Picco
2004-05-11 17:31                 ` Robert Picco
2004-05-12 18:20                 ` Andrew Cagney
2004-05-12 18:31                   ` Daniel Jacobowitz
2004-05-12 18:59                     ` Robert Picco
2004-05-12 20:55                       ` Daniel Jacobowitz
2004-05-12 22:16                         ` Robert Picco
     [not found]                     ` <40A279AF.30603@gnu.org>
2004-05-12 20:53                       ` Daniel Jacobowitz
2004-08-02 15:51                   ` Robert Picco
2004-09-24 20:07                     ` Andrew Cagney
2004-09-25 16:33                       ` Eli Zaretskii
2004-09-27 19:21                       ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40928D64.8010209@gnu.org \
    --to=cagney@gnu.org \
    --cc=Robert.Picco@hp.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox