Re: Thread-specific breakpoints

[Fabian Cenedese <Cenedese at indel dot ch>]

Hmpf, sorry for the private mail. Now also to the list.

>> Yes, that's along the lines I was thinking. And after intense looking I even
>> found it in the manual. I missed it the first time as the break command
>> is explained in 5.1.1 whereas break <location> thread <number> by itself
>> is in 5.4.
>> 
>> After looking at the communication with the stub it seems that the Z0
>> packet only informs the stub about a breakpoint but not about the thread.
>> So every thread will stop here and gdb needs to tell them to continue
>> it it's not the wanted one. That could generate quite a lot of communication
>> (important if it's a serial connection) and also changes the timing quite
>> a lot. If the breakpoint handling was in the stub the stop'n'go could be
>> made much faster without the interaction of gdb. I guess if there is no
>> other possibility I could use the "monitor" command to inform the stub
>> about the thread of the breakpoint. But then again this is difficult as the
>> breakpoints are only set once a "step" or "continue" is sent...
>> 
>> Thanks for the help anyway
>
>Yes, there's no way to set remote-assisted thread-specific breakpoints
>in the remote protocol.  This might be a good thing to add.

What about reading them back? Our embedded system is "intelligent"
(yeah, I know) and has its own breakpoint handling for various reasons
(performance, usability, security if the debugger dies...). So if we attach
to a running target we first read the available breakpoints from the system.
I think this is not only missing in the protocol but in gdb in general.

Thanks

bye  Fabi