From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 985 invoked by alias); 2 Sep 2011 05:13:51 -0000 Received: (qmail 974 invoked by uid 22791); 2 Sep 2011 05:13:49 -0000 X-SWARE-Spam-Status: No, hits=-0.7 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from ms9.webland.ch (HELO ms9smtp.webland.ch) (92.43.217.109) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 02 Sep 2011 05:13:34 +0000 Received: from macserver.private ([77.57.184.28]) by ms9smtp.webland.ch (Webland Mail Server v10.0) with ASMTP id LOP30032; Fri, 02 Sep 2011 07:13:32 +0200 Received: from localhost (localhost [127.0.0.1]) by macserver.private (Postfix) with ESMTP id E6B4DE05859; Fri, 2 Sep 2011 07:13:22 +0200 (CEST) Received: from macserver.private ([127.0.0.1]) by localhost (macserver.private [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfkTROg1QCep; Fri, 2 Sep 2011 07:13:19 +0200 (CEST) Received: from [192.168.1.18] (unknown [192.168.1.18]) by macserver.private (Postfix) with ESMTP id 361D0E0584E; Fri, 2 Sep 2011 07:13:19 +0200 (CEST) Message-ID: <4E6065F5.8090209@indel.ch> Date: Fri, 02 Sep 2011 05:13:00 -0000 From: Raphael Zulliger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: =?UTF-8?B?UGV0ciBIbHV6w61u?= CC: gdb@sourceware.org Subject: Re: Thread Specific Breakpoints in Remote Targets References: <201108311909.22045.pedro@codesourcery.com> <4E5F8753.8070003@indel.ch> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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/msg00007.txt.bz2 On 01.09.2011 23:34, Petr Hluzín wrote: > On 1 September 2011 15:23, Raphael Zulliger wrote: >> 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: 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... 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). > However > 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 [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 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. 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. 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)... > > 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? Yes, but I believe these "thread-specific"-ness is handled as stated above: by the GDB frontend. > > 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. > > [1] http://sourceware.org/gdb/current/onlinedocs/gdb/Non_002dStop-Mode.html > [2] http://sourceware.org/gdb/current/onlinedocs/gdb/Remote-Non_002dStop.html >