This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: protocol spec
- To: Quality Quorum <qqi at world dot std dot com>
- Subject: Re: protocol spec
- From: jtc at redback dot com (J.T. Conklin)
- Date: 22 Dec 1999 16:34:16 -0800
- Cc: gdb at sourceware dot cygnus dot com
- References: <Pine.SGI.3.95.991219200735.6636A-100000@world.std.com>
- Reply-To: jtc at redback dot com
>>>>> "Quality" == Quality Quorum <qqi@world.std.com> writes:
Quality> IMHO, we have to resolve just a few key issues here one way
Quality> or other, before piling new operations into remote protocol.
Quality>
Quality> 1. Do we want the remote to support per thread software
Quality> breakpoints ?
Absolutly. At the very least, we don't want to preclude the target
debug agent from supporting per thread breakpoints (of any type).
The model I was thinking of when I originally proposed the breakpoint
extensions was that it would ultimately be up to the agent whether to
implement thread specific breakpoints. GDB would make no assumptions
--- if a breakpoint fired, it would determine the thread od and would
continue target execution if a breakpoint wasn't set for that thread.
On target with a debug agent that doesn't handle thread specific
breakpoints, you might see a GDB<->debug agent dialog something like:
-> Hg05
<- OK
-> Z0,XXXX,2
<- OK
-> c
<- T05:PC=XXXX;thread=00
-> c
<- T05:PC=XXXX;thread=01
-> c
<- T05:PC=XXXX;thread=00
-> c
<- T05:PC=XXXX;thread=05
But on a system that supports thread specific breakpoints, you'd see
something like this:
-> Hg05
<- OK
-> Z0,XXXX,2
<- OK
-> c
<- T05:PC=XXXX;thread=05
This could be a substantial difference, especially when using low
bandwidth or high latency i/o channels.
--jtc
--
J.T. Conklin
RedBack Networks