Thread Specific Breakpoints in Remote Targets

[Pedro Alves]

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.

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

-- 
Pedro Alves