Re: Thread Specific Breakpoints in Remote Targets

[Raphael Zulliger <zulliger@indel.ch>]

On 31.08.2011 20:09, Pedro Alves wrote:
> On Wednesday 31 August 2011 15:47:32, Tom Tromey wrote:
>>>>>>> "Josh" == Josh Watt<jpewdev@gmail.com>  writes:
>> Josh>  As can been seen from the log, the stub is sending a message to
>> Josh>  switch to thread 1040 ($Hg410#44) right before setting the
>> Josh>  breakpoint (and again before deleting it). In subsequent
>> Josh>  operation, it is apparent that it is always switching to this
>> Josh>  thread when setting and clearing a breakpoint.
>>
>> FWIW I found your note very clear, thanks for the dump and background
>> info.
>>
>> Josh>  Because of this, our remote stub cannot rely on the currently
>> Josh>  selected thread as the target thread for a given breakpoint and
>> Josh>  must communicate with GDB every time a breakpoint is hit.
>>
>> I did not understand this though.
>>
>> It sounds like you are making breakpoints on the target thread-specific
>> based on the current thread.  But I thought we didn't (yet) have a way
>> to inform the target that a given breakpoint was thread-specific (but I
>> don't know this area extremely well -- if I'm wrong I'd like to know
>> about it).
> You're right, we don't.
Just to mention that: My company would be very interested in (optional) 
'thread specific breakpoints' support for remote targets. gdb could ask 
a gdbstub whether it supports this feature (by the qSupported packet).

In our case, our proprietary real-time OS already offers support for 
'thread specific breakpoints' and it is definitely not an option for our 
system to use the 'thread specific breakpoint emulation' performed by 
the gdb frontend today as it would disrupt real-time behavior. The lack 
of this feature causes major troubles for us during single-stepping, 
where temporary (global) breakpoints are set by the gdb frontend... to 
circumvent this "problem", I had to slightly extend the remote protocol 
for real 'thread specific breakpoints' (I just added a new breakpoint 
type (5) that also passes the Pid/Tid to the stub and which is used 
during step operations). I really hope we can make this feature (however 
it'll be implemented) part of the original gdb sometime in the future!
>
>> I think it would be preferable to
>> implement real target support for thread-specific breakpoints.
> Very much.
>
> Also:
>
>> Sending packet: $vCont?#49...Ack
>> Packet received:
>> Packet vCont (verbose-resume) is NOT supported
> ...
>> Sending packet: $s#73...Ack
> ...
>
> Please implement vCont support in your stub.  s and c
> are deprecated on multi-threaded targets.  There's no
> way to make them work correctly in some cases.
>