This is the mail archive of the gdb@sourceware.org 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 <zulliger@indel.ch> 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
thread.)
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]