This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: remote target register set?


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=http%3A%2F%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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]