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




On 22 Dec 1999, J.T. Conklin wrote:

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

My question was is it a requirement for all remotes to 
support per thread break points - I suppose it has to be optional, 
and it seems to me that you agree.

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

It seems to me that your example is incorrect:

> 
>         -> Hg05
>         <- OK

It seems to me that it has to be (we are specifying break point
in thread 5, hence Hc and we are going to do it by changing 
memory in thread 5, hence Hg 

          ->Hc05
          <-OK

>         -> Z0,XXXX,2
>         <- OK

Z does not insert software break point, it informs remote
that software breakpoint is going to be inserted.

          ->mXXXX, 2
          <-ABCD
          ->MXXXX,2:CDEF
          <-OK
>         -> c
>         <- T05:PC=XXXX;thread=00

I am wondering is current GDB that smart indeed ?

          -> z0,XXXX,2        - remove breakpoint(s)  (*)
          -> MXXXX,2:ABCD
          <- OK
          -> s
          <- T05:PC=ZZZZ;thread=00
          -> Z0,XXXX,2        - insert breakpoint(s)
          -> MXXXX,2:CDEF

>         -> c
>         <- T05:PC=XXXX;thread=01

See above.

>         -> c
>         <- T05:PC=XXXX;thread=00

See above

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

BTW, if device does not support per thread break points, there 
is no need for it to support Hc/Hg and there is no need for GDB
to send it out.


> J.T. Conklin

Thanks,

Aleksey




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