This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Thread Specific Breakpoints in Remote Targets

On 01.09.2011 23:34, Petr HluzÃn wrote:
On 1 September 2011 15:23, Raphael Zulliger<> 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).
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]