From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26567 invoked by alias); 3 Sep 2011 16:00:59 -0000 Received: (qmail 26557 invoked by uid 22791); 3 Sep 2011 16:00:57 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-fx0-f41.google.com (HELO mail-fx0-f41.google.com) (209.85.161.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 03 Sep 2011 16:00:43 +0000 Received: by fxg9 with SMTP id 9so2876952fxg.0 for ; Sat, 03 Sep 2011 09:00:42 -0700 (PDT) Received: by 10.223.61.148 with SMTP id t20mr193612fah.125.1315065642072; Sat, 03 Sep 2011 09:00:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.119.17 with HTTP; Sat, 3 Sep 2011 09:00:22 -0700 (PDT) In-Reply-To: <4E6065F5.8090209@indel.ch> References: <201108311909.22045.pedro@codesourcery.com> <4E5F8753.8070003@indel.ch> <4E6065F5.8090209@indel.ch> From: =?UTF-8?B?UGV0ciBIbHV6w61u?= Date: Sat, 03 Sep 2011 16:00:00 -0000 Message-ID: Subject: Re: Thread Specific Breakpoints in Remote Targets To: Raphael Zulliger Cc: gdb@sourceware.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-09/txt/msg00014.txt.bz2 On 2 September 2011 07:13, Raphael Zulliger wrote: > On 01.09.2011 23:34, Petr Hluz=C3=ADn 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= =3D1EE;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. --=20 Petr Hluzin