From: "Petr Hluzín" <petr.hluzin@gmail.com>
To: Raphael Zulliger <zulliger@indel.ch>
Cc: gdb@sourceware.org
Subject: Re: Thread Specific Breakpoints in Remote Targets
Date: Sat, 03 Sep 2011 16:00:00 -0000 [thread overview]
Message-ID: <CAC=yr6B=+ZEqEy8UTJxc1miHzb_L34zWfUn5jZamYXZuxX1+Rw@mail.gmail.com> (raw)
In-Reply-To: <4E6065F5.8090209@indel.ch>
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
prev parent reply other threads:[~2011-09-03 16:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-30 22:03 Josh Watt
2011-08-31 14:47 ` Tom Tromey
2011-08-31 18:09 ` Pedro Alves
2011-08-31 18:30 ` Josh Watt
2011-08-31 18:42 ` Pedro Alves
2011-09-01 15:34 ` Josh Watt
2011-10-05 17:23 ` Tom Tromey
2011-09-01 13:23 ` Raphael Zulliger
2011-09-01 21:35 ` Petr Hluzín
2011-09-01 23:57 ` Pedro Alves
2011-09-02 5:13 ` Raphael Zulliger
2011-09-03 16:00 ` Petr Hluzín [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAC=yr6B=+ZEqEy8UTJxc1miHzb_L34zWfUn5jZamYXZuxX1+Rw@mail.gmail.com' \
--to=petr.hluzin@gmail.com \
--cc=gdb@sourceware.org \
--cc=zulliger@indel.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox