This is the mail archive of the
mailing list for the GDB project.
Re: Thread Specific Breakpoints in Remote Targets
- From: Raphael Zulliger <zulliger at indel dot ch>
- To: Petr HluzÃn <petr dot hluzin at gmail dot com>
- Cc: gdb at sourceware dot org
- Date: Fri, 02 Sep 2011 07:13:25 +0200
- Subject: Re: Thread Specific Breakpoints in Remote Targets
- References: <CAEPrYjQnadK872r5dXz2-KFBsoXcpBj0CMPc3gcSmtAvcrUBpg@mail.gmail.com> <email@example.com> <firstname.lastname@example.org> <4E5F8753.email@example.com> <CAC=yr6CuoSmnmeDptKgr1=dygw+-i4AtXjFVxWODosd_4NCBDA@mail.gmail.com>
On 01.09.2011 23:34, Petr HluzÃn wrote:
On 1 September 2011 15:23, Raphael Zulliger<firstname.lastname@example.org> wrote:
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...
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: 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).
No, my problem is different. I'm actually using non-stop debugging
And therefore the 'user visible behavior' is, as stated above,
absolutely ok - but the real-time behavior is not.
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 , .
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.
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.
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)...
Yes, but I believe these "thread-specific"-ness is handled as stated
above: by the GDB frontend.
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.