This is the mail archive of the gdb@sourceware.cygnus.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]

Re: remote protocol extensions for reading and writing registers


"J.T. Conklin" wrote:

> Hmmm.  When I implemented the `T' response this for our x86 stub, I
> set remotedebug and watched the protocol as I stepped through code.
> GDB always requested all registers immediately after taking control
> until I added the PC, SP, and BP.  I suspect the optimal set of
> registers to return in a `T' response depends on the processor.

(Ah, yes, that VAX in sheeps clothing :-).
A few more targets could do with that extra bit of analysis.
 
> This seems to indicate that there should be some mechanism in the
> protocol such that GDB and the stub identify to each other the maximum
> MTU that can be used; And that any register transfer command have the
> ability to split the command (or the results) over multiple packets.

I think Mark Salter (cygnus) would be very interested in this idea.

> Perhaps P/p could be extended to fetch/set more than one register at a
> time similar to the `T' response.  At least for setting registers, GDB
> could have a `register cache' and only write regs just before program
> execution is resumed (perhaps this wouldn't work with MSRs though, in
> those cases, you might want the side effect of setting those registers
> to take effect immediately).

Until I went over the ``P'' packet carefully I thought it could take a
list of registers :-(

I don't think we could extend the existing P/p packets.  Looking at one
stub it just assumes it is getting REGISTER_RAW_SIZE bytes and blindly
discards anything following that -> we couldn't detect a target that
didn't support any extension.

(As a gripe, I wish P/p were network byte ordered... :-)

> Andrew> One idea I've played with is having GDB query the target for a
> Andrew> table of special register names/numbers.  GDB could then
> Andrew> augment the existing register name lookup table with that
> Andrew> list.  The special purpose registers would be requested
> Andrew> individually using (P/p).
> 
> Do you have any idea about how these queries would be implemented?

No, It's an idea :-)

My guess would be an exchange like

	<-	qSPRs
	->	spc,AA1;fscfgr,A2A;....

then:

	<-	vAA1,A2A
	->	-A67C,56F
or	->	AA1,-A67C;A2A,56F

and	<-	vAA1,-A67C;A2A,56F
	->	OK

Andrew

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