protocol spec

J.T. Conklin jtc@redback.com
Wed Dec 22 16:34:00 GMT 1999


>>>>> "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


More information about the Gdb mailing list