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: protocol spec


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

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