to_query target_ops entry

to_query target_ops entry

[Doug Evans]

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

Re: to_query target_ops entry

[Fernando Nasser]

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.



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

Re: to_query target_ops entry

[Doug Evans]

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

Re: to_query target_ops entry

[Fernando Nasser]

Doug Evans wrote:
> 
> 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.  */
> 

I cannot look at the code now, but this seems quite right.


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