Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Doug Evans <dje@transmeta.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: gdb@sources.redhat.com
Subject: Re: to_query target_ops entry
Date: Fri, 23 Feb 2001 14:34:00 -0000	[thread overview]
Message-ID: <14998.58726.866822.724540@casey.transmeta.com> (raw)
In-Reply-To: <3A96E2AC.3401D8C9@cygnus.com>

Fernando Nasser writes:
 > Doug Evans wrote:
 > > 
 > > Is the intendend usage of the `to_query' target_ops entry documented anywhere?
 > > I can kinda guess from studying kod.c:gdb_kod_query, but my guessing
 > > is incomplete (and often wrong).
 > 
 > It is just an access to query things on a target.  The main use is to access OS data independently on the type of communication channel or if the OS is remote or native.
 > 
 > If the target is a "remote" one (I guess it is the only one that currently implements this), a 'q' packet will be sent and the first argument (type) will be sent as a single character after the 'q'.
 > 
 > Other targets may do things differently, but you should get back the value (as a string) of whatever target object you have requested.

Thanks for the response.
I figured the data is pretty well target-specific.
I'm locally adding a `sim_query' function to remote-sim.h
[with appropriate additions to remote-sim.c].

But as for the intended argument usage, here's what I wrote up.
Let me know if this is wrong, too constrained, or not constrained enough.
I wanted this to be rather constrained to avoid future headaches.

/* Query the simulator for something (this is the `to_query' target_ops entry).
   What it is is up to the simulator.

   TYPE is a printable character.  Pass '-' for "don't care".
   If there is a failure, the error message is in RESP.
   SIZE is the maximum size of both REQ and RESP.
   REQ is a string containing the request.
   The contents of RESP are up to the request.

   If REQ is NULL, the caller is requesting the maximum request size.
   On return the maximum size is stored in *SIZE.
   Otherwise SIZE is unchanged on return.

   The result is 0 for success, non-zero for failure.
   If the simulator doesn't implement this, it always returns -1 and
   "not implemented" is stored in RESP.
   RESP is assumed to be at least MIN_SIM_QUERY_SIZE bytes in size.  */

#define MIN_SIM_QUERY_SIZE 16

extern int sim_query (SIM_DESC sd, int type, char *req, char *resp,
		      int *bufsize);


  reply	other threads:[~2001-02-23 14:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-23 14:07 Doug Evans
2001-02-23 14:23 ` Fernando Nasser
2001-02-23 14:34   ` Doug Evans [this message]
2001-02-23 14:45     ` Fernando Nasser

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=14998.58726.866822.724540@casey.transmeta.com \
    --to=dje@transmeta.com \
    --cc=fnasser@cygnus.com \
    --cc=gdb@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