remote target register set?

[Andrew Cagney]

Hello,


> It also appears that the powerpc:common architecture setting has added the
> AltiVec register set sometime between gdb 5.1 and the latest version.
> Consequently I am unable to have a "common" target in my simulator that
> works with various versions of gdb.

I'm not sure what you mean here.  Your simulator can send back a short G 
packet that contains just the GPR and FPU registers.

> Is there a way for gdb to let the remote target know what registers it will
> be expecting for the read and write register commands?  If not, would it be
> worthwhile to add one?  It would be helpful to know the name, size, and
> order of all registers that will be used for the current debugging
> session.  Without knowing much about the remote debugging protocol,
> something like the following might work:
> 
>    query register info support:    qRegInfo?
>    response:                       OK  - willing to accept register info
>                                    ''  - not willing to accept register info
>    
>    send register info              qRegInfo:n,s;n,s;
>                                    Where 'n' is the name of the register
>                                    being defined, and 's' is the size, in
>                                    bytes, of this register.  The order is
>                                    the order within the read/write register 
>                                    command.
>    response :                      OK - all is understood
>                                    E?? - This target cannot work with the
>                                    current gdb architecture.

See:
http://sources.redhat.com/ml/gdb-patches/2002-09/msg00505.html
for the most recent post on this problem.

I believe the current consensus is for the remote protocol register 
layout to be specified by a gdb/regformats/reg*.dat file  Your simulator 
would provide such a file and then GDB would load and use it (hmm, I 
guess an extension would be to have GDB directly query the target for 
the register format ....).

Regarding the above, I think it would work with a simulator (which has 
plenty of ram) but not with an embedded stub where there may not be the 
memory footprint available to implement this.

> p.s. It would also be useful to know the registers that are required for
> the expedited response from the target.

Figuring out which registers to expedite is, unfortunatly, a black art.

Try something like setting a breakpoint regcache_raw_read() with a 
command to print the register number being fetched.  Then do a backtrace 
(``(gdb) bt'') and see which registers are fetched.

See also:
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=167&return_url=https%3A%2F%2F2.zoppoz.workers.dev%3A443%2Fhttp%2Fsources.redhat.com%2Fcgi-bin%2Fgnatsweb.pl%3Fdatabase%3Dgdb%26cmd%3Dsubmit%2520query%26category%3Dall%26severity%3Dall%26priority%3Dall%26responsible%3Dall%26submitter_id%3Dall%26state%3Dall%26ignoreclosed%3DIgnore%2520Closed%26class%3Dall%26synopsis%3D%26multitext%3DT%2520packet%2520%26columns%3Dcategory%26columns%3Dstate%26columns%3Dpriority%26columns%3Dresponsible%26columns%3Dsynopsis%26displaydate%3DDisplay%2520Current%2520Date%26sortby%3DResponsible%26.cgifields%3Dcolumns%26.cgifields%3Doriginatedbyme%26.cgifields%3Ddisplaydate%26.cgifields%3Dignoreclosed

Andrew