Re: Thread Specific Breakpoints in Remote Targets

[Petr HluzÃn <petr dot hluzin at gmail dot com>]

On 1 September 2011 15:23, Raphael Zulliger <zulliger@indel.ch> wrote:
> On 31.08.2011 20:09, Pedro Alves wrote:
>>
>> On Wednesday 31 August 2011 15:47:32, Tom Tromey wrote:
>>> 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, ...

I think GDB's thread-specific breakpoints do something different than
you expect: if user sets breakpoint specific to thread 5 then the
other threads do not trigger the breakpoint (so far so good). However
when the thread 5 arrives at the breakpoint then GDB stops _all_
threads even if the breakpoint was thread-specific.

If you want to break only the thread which arrived at the breakpoint
location and have the other threads continue running, then implement
GDB's Non-Stop Mode [1], [2].

I think the thread-specific breakpoints will be almost unnecessary
when you implement the non-stop mode. Users usually debug their own
code which may live in multiple threads and specifying even one thread
condition is slowdown. Of course if users place a breakpoint in a
library used by multiple threads, then the thread-specific breakpoints
will be useful.

Still, the ability of thread-specific breakpoints would be useful to
other remote stubs.

By the way: when user does "next", "step", or "finish" GDB places a
temporary internal breakpoint. Is the breakpoint thread-specific?

I think it would be confusing to do "next" and wake up a different
thread. Some IDE do not notify the user about the different thread.
Furthermore the different thread may have identical stack (but
processing unrelated data).
Anyway it is difficult for the user to return to the correct thread
since the frame of interest will be buried under sub-procedures the
user was next-ing over and he may not even know the thread ID. Plus
the next "next" may do the nastiness again. It would be useful if GDB
placed thread-specific breakpoints for the commands.

[1] http://sourceware.org/gdb/current/onlinedocs/gdb/Non_002dStop-Mode.html
[2] http://sourceware.org/gdb/current/onlinedocs/gdb/Remote-Non_002dStop.html

-- 
Petr Hluzin