Re: Thread Specific Breakpoints in Remote Targets

[Raphael Zulliger <zulliger@indel.ch>]

On 01.09.2011 23:34, Petr Hluzín wrote:
> On 1 September 2011 15:23, Raphael Zulliger<zulliger@indel.ch>  wrote:
>> 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).
AFAIK: From point of view of the GDB stub, the breakpoint specific to 
thread 5 is actually a "global breakpoint". I think this is the case due 
to the fact that I couldn't find a 'thread specific breakpoint' facility 
within the gdb remote protocol. Moreover, when such a breakpoint is set 
within the gdb frontend, my gdbstub just receives the command for 
setting a breakpoint along with an address but now pid/tid information...

AFAIK: What finfally makes a "thread specific breakpoint" thread 
specific is the way how the gdb frontend handles a breakpoint hit of an 
unrelated thread: GDB will silently continue that unrelated thread. This 
mechanism leaves the user of gdb under the impression that a breakpoint 
is thread specific - but technically, the breakpoint which has been 
inserted in the inferior is global and will be hit by every thread! 
This, of course, adds a major (and undeterministic) delay to each 
unrelated thread that hits the breakpoint. This is not acceptable in a 
real-time system (at least not in ours).
> 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].
No, my problem is different. I'm actually using non-stop debugging 
("multiprocess+;QStartNoAckMode+;QNonStop+;qXfer:threads:read+;PacketSize=1EE;qXfer:osdata:read+"). 
And therefore the 'user visible behavior' is, as stated above, 
absolutely ok - but the real-time behavior is not.
>
> 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.
You may judges the following a bad design/architecture - but our 
real-time os lives in the very same address space as the complete user 
code (mainly because of efficiency reasons). Moreover, high priority 
real-time threads are typically using the very same classes/functions as 
others do. Therefore, a typical debugging session will indeed cause 
unrelated threads hit breakpoints when single stepping.

In short: I partially agree with your point - but for the our system it 
is indeed "a real world problem" (not just a nice to have)...
>
> 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?
Yes, but I believe these "thread-specific"-ness is handled as stated 
above: by the GDB frontend.
>
> 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
>