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 2 September 2011 07:13, Raphael Zulliger <> wrote:
> On 01.09.2011 23:34, Petr HluzÃn wrote:
>> 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).
> ...
>> 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 was not aware that your system requires more real-time behavior.
(Most systems can tolerate the ~30ms delay when GDB checks current
Because you already implement the non-stop mode my suggestion is irrelevant.

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

Actually your design/architecture are fine - debug stubs are often
done this way on embedded stuff. One can get breakpoint hit delay
under 10 us. Plus you do not need JTAG adapter etc.

Petr Hluzin

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